-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fewer dependencies for the container image #490
Conversation
This got me thinking... Should we name and/or tag the artifacts better? Naming them something like |
- The entrypoint in the container image will create the CITEXT extension in the database if needed. - The container image is built with default mregsite and logs directories, so it can run without these being mounted into it. - A docker-compose.yml file is added to the repo. - The section about Docker in the README file is updated.
When using entrypoint-test.sh, the CITEXT extension ended up being created in the regular mreg database, when it needs to be created in the template1 database so it propagates to the temporary database created by manage.py test.
775187c
to
b73ed70
Compare
Good idea, let's do that, but not in this pull request. I created an issue |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. The create_citext_extension is great to have.
Also, add a few words to README.md about dependencies for PostgreSQL
This PR does the following:
The container-image.yml workflow is modified to trigger on pushes to all branches, but only push the built image to ghcr.io if the branch is master. This way, we get to test that workflow on new code before merging into master.Done in 749d096