Remove builder-base and development image stages, run linting and tests outside Docker
#111
Conversation
Now, we only have two Dockerfile stages: - `base`, where we install dependencies with poetry - `production`, where we copy the sources files and run the app We use environment variables to run the app in a "nonprod" or "prod" mode We also ad a .dockerignore file to limit the files that make it into the production container
There was a problem hiding this comment.
Wao 🤯 big shrink!
Weird, the missing PORT var is blocking the build on my env, and it wasn't caught in the Github Action build...
Should we have a Github Action that does a make start and curl --connect-timeout 30 --retry 300 --retry-delay 5 http://localhost:8000/ to make sure we don't break anything in docker-compose?
And I'm also facing #107, but I guess you don't, and it can be fixed in another PR.
$ make start
docker-compose up
/opt/homebrew/lib/python3.9/site-packages/paramiko/transport.py:236: CryptographyDeprecationWarning: Blowfish has been deprecated
"class": algorithms.Blowfish,
Creating jira-bugzilla-integration_web_1 ... done
Attaching to jira-bugzilla-integration_web_1
web_1 | ERROR (catatonit:2): failed to exec pid1: Permission denied
jira-bugzilla-integration_web_1 exited with code 1
Random driveby: what would you think about prefixing makefile targets that go through Docker with container- or docker-?
eg. make start vs make docker-start
I'm not familiar with this. What does it mean? |
I'm also not really sure what this means -- I think it's because we have this configured in our Github actions? See this deployment / environment documentation. |
- add `docker-` prefix for shell and start rules - add a local start rule - modify help text
Good idea 849788e |
I missed your previous comment. I looks like we don't use these features. Even if that does not seem to affect anything, I would be in favor of removing anything that we don't use, and keep only the strict necessary and sufficient stuff |
In this PR, we:
developmentandbuilder-basestages of the Dockerfile so all that's left is abasestage for downloading Python dependencies and aproductionstage for running the application code. We still run the image in a "development" mode locally through the use of environment variables and overriding the image'sCMDinstruction..dockerignoreso that only application code ends up in the production imageCloses #110