Closed NoRePercussions closed 5 months ago
The lifecycle of the development containers seems pretty automatable. What do you think about including some make
targets for development?
I'd also personally like to include a healthcheck, but I don't want to deviate too far from the rails template.
The lifecycle of the development containers seems pretty automatable. What do you think about including some
make
targets for development?
We could, but ideally in the end I think it would condense down to:
docker compose up --file compose_dev.yaml
docker exec -it tracker rails c # for initial member account
That way you don't even have to setup SQL. The compose_dev.yaml
could build the repo locally and the compose.yaml
(for production) would pull from the GitHub container registry.
I'd also personally like to include a healthcheck, but I don't want to deviate too far from the rails template.
When we reach Rails 7 there is this: https://edgeapi.rubyonrails.org/classes/Rails/HealthController.html
Great. I think I've addressed all comments, so what remains is whatever remaining comments you have.
It seems like after this PR, next steps in dockerizing may be
Great! I have a standard GitHub action for dealing with GHCR I can push later tonight.
I think we should try to tackle #544 as a part of this. The current email process and Sphinx process are trivial to run in Docker Compose with the same container, but the Slack notification runs on a Systemd timer. That Systemd service can just become a docker exec
but it would be better to be self-contained.
A mostly-functional Docker environment for tracker.
Some things this doesn't include: