James Cottrill 80dfc15319 ci: release workflow — build + push container images to GHCR on release (#6) ...

* feat: add release workflow to build and push container images to GHCR

Triggers on GitHub Release publish. Builds three container images
(consentos-api, consentos-scanner, consentos-admin-ui) and pushes
them to ghcr.io/consentos/ tagged with the semver release version
(e.g. v1.0.0, 1.0), plus ``latest``.

Release flow:
  1. Merge PRs to master.
  2. Tag: ``git tag v1.0.0 && git push origin v1.0.0``
  3. Create a GitHub Release from the tag.
  4. Workflow fires, images land on GHCR.
  5. Deploy by pointing Helm values or docker-compose at the tag.

Uses ``docker/metadata-action`` for tag derivation and
``docker/build-push-action`` for the builds. Auth uses the
default ``GITHUB_TOKEN`` with ``packages: write`` — no extra
secrets needed.

The admin-ui image uses the repo root as the build context (same
as ``docker-compose.prod.yml``) so the Dockerfile can pull in
``apps/banner/`` alongside ``apps/admin-ui/`` and bundle the
banner output at the nginx root.

* chore: auto-graduate changelog on release + CI path filters

CI workflow (``ci.yml``):
  - Uses ``dorny/paths-filter`` to detect which apps changed. Each
    job group (api, scanner, banner, admin-ui) now has an
    ``if: needs.changes.outputs.<app> == 'true'`` guard so it only
    runs when files under its ``apps/<app>/`` directory were
    modified. A docs-only or infra-only PR no longer triggers the
    full lint + test + build matrix.

2026-04-18 16:14:40 +01:00

720 B

Raw Blame History

View Raw