Use NginX as web server

[sindre-nistad]

Why is this pull request needed?

It removes the need for a separate container, whose only job is to serve static files.

What does this pull request change?

It moves all the NginX configuration into web, so that we can use a multistage build for the web server.
It preserves hot-reloading when running locally

Issues related to this change:

• [Suggestion] Let NginX serve the static files generated by Node.js #203

[github-advanced-security]

You have successfully added a new CodeQL configuration .github/workflows/on-pull-request.yaml:analyze/language:javascript. As part of the setup process, we have scanned this repository and found 1 existing alert. Please check the repository Security tab to see all alerts.

[github-advanced-security]

You have successfully added a new CodeQL configuration .github/workflows/on-pull-request.yaml:analyze/language:python. As part of the setup process, we have scanned this repository and found no existing alerts. In the future, you will see all code scanning alerts on the repository Security tab.

[netr0m]

Nicely done! Definitely an improvement for production deployments. Just a few remarks on trivial matters.

[soofstad]

Look great! :D
Might want to update radixconfig.yaml as well. Does not look like it will work deployed like this

[sindre-nistad]

Look great! :D
Might want to update radixconfig.yaml as well. Does not look like it will work deployed like this

Forgot to update it. Will do

[sindre-nistad]

Look great! :D
Might want to update radixconfig.yaml as well. Does not look like it will work deployed like this

Forgot to update it. Will do

@soofstad Is there an easy way to test the new radix configuration?

[soofstad]

Look great! :D
Might want to update radixconfig.yaml as well. Does not look like it will work deployed like this

Forgot to update it. Will do

@soofstad Is there an easy way to test the new radix configuration?

Nope. Fingers crossed and deploy to test

[sindre-nistad]

@soofstad , @netr0m : Any ideas as to why the api tests fail?
I tried executing docker-compose -f docker-compose.yml -f docker-compose.ci.yml run --rm api pytest --integration (same as in the GitHub Action) locally, and it seems to work.

[netr0m]

@soofstad , @netr0m : Any ideas as to why the api tests fail? I tried executing docker-compose -f docker-compose.yml -f docker-compose.ci.yml run --rm api pytest --integration (same as in the GitHub Action) locally, and it seems to work.

Well, it seems the poetry install command fails - the workflow outputs:

[...]
Step 11/14 : RUN poetry install
[...]
  ChefBuildError

  Backend 'setuptools.build_meta:__legacy__' is not available.
[...]

Note: This error originates from the build backend, and is likely not a problem with poetry but with sentinels (1.0.0) not supporting PEP 517 builds. You can verify this by running 'pip wheel --use-pep517 "sentinels (==1.0.0)"'.

I found the following from a quick search - seems like a recent change (upstream, poetry or some other build dependency) has caused something to break?

• Identical issue, no solution: Can't install fire with poetry inside of docker google/python-fire#445
• Similar issue, proposed solution ERROR Backend '<backend>' is not available pypa/packaging-problems#506 (comment)

I guess it might relate to us not being explicit about which poetry version we'd like to use? I.e., in the api/Dockerfile, we accept any version of poetry, which will break stuff at some point.

Also, did you do a fresh build of the Docker image prior to running the docker-compose / pytest locally?