Skip to content

Build and push images from GitHub Actions - #157

Open
grahamgilbert wants to merge 4 commits into
masterfrom
gh-actions-release
Open

Build and push images from GitHub Actions#157
grahamgilbert wants to merge 4 commits into
masterfrom
gh-actions-release

Conversation

@grahamgilbert

Copy link
Copy Markdown
Owner

Why

CircleCI is not building anything. The org shows LAST RUN: Not yet! on every project, 0 workflow runs over 30 days, and GET /api/v2/project/gh/grahamgilbert/Crypt-Server/pipeline returns an empty list. The most recent tag on Docker Hub is 3.4.1 from November 2022; latest last moved 2025-01-29, almost certainly by hand.

So pushing the 3.4.2 tag built nothing. This moves image builds to GitHub Actions.

What changed

  • .github/workflows/docker.yml — on a tag push, build and publish macadmins/crypt-server:<tag>; on a master push, move :latest. Then dispatch the crypt-server-saml build, which layers on top of this image.
  • Deleted .circleci/config.yml and remote_build.py. Both are dead, and if the CircleCI org were ever reconnected its build_latest/build_tag jobs would race this workflow pushing the same tags.
  • Dropped the now-stale .circleci/ and remote_build.py entries from .dockerignore.

set_build_no.py is deliberately kept — docs/Development.md documents it as a pre-commit hook, and version.plist is read by fvserver/context_processors.py and server/views.py.

Migration gate

The build uses load: true and pushes only after manage.py migrate succeeds inside the built image. docker/run.sh applies migrations at container startup, so a migration that imports cleanly but fails to apply would otherwise be published and break on deploy. With no DB_* env set, docker/settings.py falls back to sqlite, which is what run.sh sees.

This is a stronger check than the CircleCI job it replaces: that one tested a fresh pip install on a different base image, this tests the artifact that actually ships.

Required secrets

Nothing will run until these exist:

Secret What
DOCKERHUB_USER / DOCKERHUB_TOKEN Docker Hub token with push rights to macadmins
SAML_DISPATCH_TOKEN Fine-grained PAT, contents: write on crypt-server-saml (GITHUB_TOKEN cannot dispatch cross-repo)

Not done here

  • No lint gate. black --check already fails on docker/settings.py on master, so adding the gate would block the release on a pre-existing failure. Worth a follow-up: fix the formatting, then add the gate.
  • version.plist is stale at 3.4.1.378, so the UI reports the old version. Pre-existing, unrelated to this change.
  • amd64 only, matching what shipped before. arm64 via QEMU would roughly double build time.

Testing

None of this has executed — the YAML and step structure are validated, and the sqlite fallback verified by reading docker/settings.py against docker/run.sh, but the first real run will be in CI. Pairs with grahamgilbert/crypt-server-saml PR.

🤖 Generated with Claude Code

grahamgilbert and others added 4 commits July 27, 2026 17:53
The CircleCI org has no pipeline history at all - every project reads
"LAST RUN: Not yet!" and the v2 API returns an empty pipeline list - so
tag pushes have not built anything for some time. The 3.4.1 tag on Docker
Hub dates from Nov 2022.

Replace it with a workflow that pushes macadmins/crypt-server:<tag> on
tag pushes and moves :latest on master, then dispatches the
crypt-server-saml build, which layers on top of this image.

Requires DOCKERHUB_USER, DOCKERHUB_TOKEN and SAML_DISPATCH_TOKEN secrets.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docker/run.sh applies migrations at container startup, so a migration that
imports cleanly but fails to apply would get published and only break on
deploy. The old CircleCI config gated image builds on manage.py migrate;
that gate went away with it.

Build with load: true instead of pushing directly, run migrate inside the
built image, and only push if it succeeds. This checks the artifact that
actually ships, rather than a pip install on a different base. With no DB_*
env set, docker/settings.py falls back to sqlite, which is what run.sh sees.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant