fix: make the compose setup work with Actyze 0.1.1 - #4
Open
roman1887 wants to merge 1 commit into
Open
Conversation
Step 4 of the release process in the dashboard repository's VERSIONING.md requires pinning this repository's compose defaults to each release. That was missed for 0.1.1, and the defaults here were not merely stale - the compose file would not have worked against 0.1.1 at all. Three incompatibilities, all consequences of the 0.1.1 hardening work: - The frontend container runs unprivileged and listens on 8080 rather than 80, so the "3000:80" mapping pointed at nothing. Published port is unchanged, so the dashboard is still at http://localhost:3000. - curl was removed from the Python images, where it existed only to run a HEALTHCHECK and was itself a source of HIGH findings. Five health checks shelled out to it and would have reported every service unhealthy. They now use a Python stdlib request, matching what the dashboard repository's compose file does. - The frontend health check used curl against port 80. It now uses wget, which its base image provides, against 8080. Also bumps the six image defaults from 0.1.0 to 0.1.1. That matters beyond freshness: the 0.1.0 prediction worker images do not start at all, failing on ImportError for configure_logging, so anyone running the previous default had three containers restarting continuously. Verified with docker compose config, and no 0.1.0 references remain.
|
Rohit Mangal seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Step 4 of the release process in
dashboard's VERSIONING.md requires pinning this repo's compose defaults to each release. That was missed for 0.1.1 — and the defaults here were not merely stale. The compose file would not have worked against 0.1.1 at all.Three incompatibilities
All are consequences of the 0.1.1 container hardening:
"3000:80"pointed at nothing — dashboard unreachablecurlremoved from the Python imagescurlon port 80The published port is unchanged, so the dashboard is still at
http://localhost:3000.Health checks now use a Python stdlib request, matching what
dashboard's own compose file does. The frontend useswget, which its base image provides.Version bump matters beyond freshness
Defaults move from
0.1.0to0.1.1for all six images. The 0.1.0 prediction worker images do not start at all — they fail onImportError: cannot import name 'configure_logging'— so anyone running the previous default had three containers restarting continuously.Verification
docker compose configvalidates0.1.0references remaindashboardrepo compose fileWhy this was missed
The same reason the two Helm chart copies drifted: deployment artifacts live in separate repositories and are synced by hand. The release checklist names this repo, but nothing enforces it — a release can be tagged, images published, and charts updated while this repo silently stays on the previous version.
Worth considering a release check that fails when this repo's pinned defaults do not match the latest
dashboardrelease.