Releases and images

Version numbers, container images and how the documentation follows each release.

Images

The images are private; every host needs docker login ghcr.io with a token that has read:packages.

A release

1. A tag vX.Y.Z in the Asterion repository builds Polaris and Pulsar, runs both test suites, then starts them together: the satellite must register and deliver a check result. Only then are the version tags and the GitHub release created. A failed release publishes nothing but candidate-* tags.
2. A Polaris release carries the digest of the Pulsar it was tested with, so its deployment snippets always use exactly that image. The release’s docker-compose.yml pins Polaris by digest.
3. The documentation of the release is refreshed (generated reference, screenshots from the demo data, changed pages) and the docs repository gets the same tag vX.Y.Z, which builds asterion-docs:X.Y.Z.

Running satellites are never updated automatically; the satellite list marks those running another version.

Keeping the documentation current

The docs repository has a refresh script that is run for every release against the release commit:

tools/refresh.sh ../asterion

It starts a throw-away Polaris with an empty database, fills it with the demo data (php artisan asterion:demo: a fictional company on documentation addresses), exports checks, defaults, environment variables, scheduler and schema, renders the diagrams, takes the screenshots, and builds the site. The build fails when

• an environment variable, table or finding type has no description,
• a screenshot or diagram a page uses is missing,
• a page that Polaris links to (App\Support\DocsLinks) does not exist.