Release: single version source, traceable images

Why?

There is no consistent version or release process:

Versions disagree: pyproject.toml says 0.2.0, deployment/Chart.yaml has version: 2.0.0 and appVersion: 2.0.0, the service-info config says 1.0.0-dev-20201108.e0358db, and docker-compose.yaml names the image 0.1.0.
There are no Git tags or GitHub releases.
The publish job in checks.yaml pushes images tagged only latest and the build date (YYYYMMDD), via philips-software/docker-ci-scripts, so an image cannot be traced back to a commit, and two pushes on the same day overwrite each other. values.yaml pins elixircloud/cloud-registry:20240716.

How?

One version source (e.g. pyproject.toml or a Git tag via setuptools-scm); read it everywhere else (service-info version default, docs).
Release from tags (same approach as FOCA: tag vX.Y.Z on main, GitHub release with notes).
Build and push images with docker/metadata-action + docker/build-push-action: semver tags on releases, plus SHA (and optionally date) tags on dev.
Set the chart's appVersion to the released image tag and use it as the default image tag in values.yaml.

Acceptance criteria

Every image can be traced to a commit; releases have semver image tags.
Package, chart appVersion and default image tag agree for a release.
A first release is tagged after Cloud Registry backend: public read access, service ownership, ECP_CLN:ADMIN admin role #62.

Dependencies: after #62; coordinate with #82 / #67.

Decided (2026-10-20): the same release strategy as FOCA. To be implemented as the last change before this week's redeploy:

One version source: the Git tag. setuptools-scm derives the version from signed vX.Y.Z tags; nothing else stores it (the service info's version comes from the package metadata, feat!: serve service info from config only #100). Docker builds don't see .git, so the workflow passes the version as a build argument; local builds report 0.0.0.dev0.
Branches: main only fast-forwards to released commits of dev.
Release workflow on tags: checks that the tag is on main, builds and pushes the image (X.Y.Z, and latest for the highest stable release), packages the Helm chart with version and appVersion set from the tag (chart and app versions move in lockstep), and creates a GitHub release with generated notes and the chart attached. No PyPI (the app is deployed as an image). A release environment with a required reviewer guards the push, as the pypi environment does in FOCA.
Images from dev: tagged dev and sha-<commit>, never latest, so that test deployments are traceable. The date tags (and philips-software/docker-ci-scripts) go away.
First release: 0.3.0. 1.0.0 is reserved for implementing the next (likely breaking) version of the GA4GH Service Registry spec. The chart version drops from 3.0.0 to 0.3.0, which is harmless because no chart was published and the redeploy is a fresh install.

Navigation Menu