Skip to content

fix: make the compose setup work with Actyze 0.1.1 - #4

Open
roman1887 wants to merge 1 commit into
mainfrom
fix/0.1.1-compat
Open

fix: make the compose setup work with Actyze 0.1.1#4
roman1887 wants to merge 1 commit into
mainfrom
fix/0.1.1-compat

Conversation

@roman1887

Copy link
Copy Markdown
Collaborator

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:

Problem Effect
Frontend now listens on 8080, not 80 (runs unprivileged) "3000:80" pointed at nothing — dashboard unreachable
curl removed from the Python images 5 health checks shelled out to it — every service would report unhealthy
Frontend health check used curl on port 80 Wrong binary and wrong port

The 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 uses wget, which its base image provides.

Version bump matters beyond freshness

Defaults move from 0.1.0 to 0.1.1 for all six images. The 0.1.0 prediction worker images do not start at all — they fail on ImportError: cannot import name 'configure_logging' — so anyone running the previous default had three containers restarting continuously.

Verification

  • docker compose config validates
  • No 0.1.0 references remain
  • Health check syntax mirrors the equivalents already running in the dashboard repo compose file

Why 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 dashboard release.

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.
@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.


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.

@github-actions github-actions Bot added the bug Something isn't working label Aug 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants