ci: automate Keycloak theme deploys to staging - #6
Merged
Merged
Conversation
Keeps node_modules, build output and .git out of the build context.
Multi-stage: node+JDK+Maven builds the Keycloakify jar, then it is copied into quay.io/keycloak/keycloak:24.0.0 and registered with `kc.sh build`. Three things this settles: - The jar is copied *by name*. Keycloakify emits one jar per Keycloak version range; a glob would put several themes into providers/ and let Keycloak pick one. - `kc.sh build` is required. Providers register at build time, so a jar dropped into providers/ on a running server does nothing. Staging has no build step today, which is why it re-augments for ~16s on every start. - KC_DB / KC_HEALTH_ENABLED / KC_METRICS_ENABLED / KC_HTTP_RELATIVE_PATH are build-time options in KC 24. Setting them only in compose (as staging does) triggers that re-augmentation regardless. Baked in here to match. The image carries the source commit and the theme jar's sha256 as labels, so `docker inspect` answers which theme a box is running.
Builds the image in CI, pushes it to GHCR, and has the staging box pull it -- replacing the manual build-jar/scp/rebuild-on-the-box process that on 2026-08-27 left staging running a seven-month-stale theme copied from a retired server, with nothing logging an error. Mirrors deploy-backend.yml in DataSpaceBackend: digest-pinned image, health gate, automatic rollback to the previously-running image. workflow_dispatch only for now, taking a ref input. push-to-main is left disabled because main does not yet carry the theme work on fix/login-ui-alignment, so auto-deploying it would regress staging.
The deploy job's own GITHUB_TOKEN can authenticate the box's `docker compose pull`, and it expires with the run. That drops the GHCR_TOKEN secret entirely and leaves no standing registry credential on the auth server; a trap logs out on every exit path.
github.repository is CivicDataLab/DataSpaceKeycloakTheme; Docker rejects uppercase in image references, so the digest-pinned image_ref would have been invalid on the box.
dev becomes the integration branch for staging -- what is merged there is what staging runs. A push trigger also means the workflow does not need to sit on the default branch first, which workflow_dispatch would require. workflow_dispatch is kept for deploying an arbitrary ref on demand.
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
1 participant
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.
Replaces the manual build-jar / scp / rebuild-on-the-box process for the staging Keycloak with a CI-built image that the box only pulls.
Why
On 2026-08-27 staging was found running a theme jar built 2025-07-14 — seven months stale —
scpd from a retired server rather than from current production. Nothing errored: the theme name matched, the jar was inproviders/, Keycloak started clean. The only symptom was a wrong-looking login page, and diagnosing it took comparing sha256 sums across three servers.What
Dockerfile— multi-stage. Node + JDK + Maven builds the Keycloakify jar; it is copied by name intokeycloak:24.0.0and registered withkc.sh build..github/workflows/deploy-keycloak-staging.yml— build → push to GHCR → SSH →docker compose pull && up -d→ health gate → auto-rollback. Mirrorsdeploy-backend.ymlin DataSpaceBackend..dockerignore.The image carries the source commit and the theme jar sha256 as labels, so "which theme is this box running, from which commit" is one
docker inspect.Verified locally
keycloak-theme-for-kc-all-other-versions.jar(2,358,300 B vs production's 2,351,205 B — right ballpark).kc.sh buildsucceeds, and a container from this image starts with zero Quarkus augmentation (staging currently pays 16.4s on every start) and is ready in ~9s./auth/health/readyreturns 200 — confirmed on the running staging box too, which already hasKC_HEALTH_ENABLED=true.serverinforeportskeycloakify-starterregistered as both a login and an email theme, which is exactly what theDataSpacerealm references. No realm-side change needed.Notes
workflow_dispatchonly.push: mainis deliberately left disabled —maindoes not yet carry the theme work onfix/login-ui-alignment, so auto-deploying it would regress staging.ci.yaml(version-bump → GitHub Release jars) is untouched.keycloak-stagingGitHub Environment. Reusingdevelopmentwould deploy Keycloak images onto the backend dev box.image:instead ofbuild:in its compose file. Done separately.