Commit Graph

2 Commits

Author SHA1 Message Date
Darko Gjorgjijoski
3a989923d1 ci: reduce the release workflow to what it still does, rename to publish.yaml (#724)
Most of docker.yaml was doing work that was duplicated or hazardous now
that releases are cut from a tag.

The tests were duplicated exactly: release.yaml and docker.yaml called
the same reusable tests.yaml, on the same commit — once before drafting,
again after publishing. No new information, and the image build queued
behind it. Pint likewise: check.yaml already style-checked the commit
when it landed. Both jobs go; coverage is unchanged.

manual_docker_build goes too, and it was worse than redundant. Its
checkout took no ref, so it built the dispatched branch while tagging
with whatever string was typed — an image could be labelled 2.4.2 while
containing 2.x HEAD — and `tag` defaulted to "latest", so a careless
dispatch republished the moving stable tag from a branch. #710 had to add
a guard purely to stop the registration dispatch doing that by accident.
It was last used in September 2025 to push the legacy and alpha tags
during the Docker distribution work; that is finished, and releases
produce images now. A patched base image is better served by a patch
release than by silently changing what a pinned tag contains.

That cascade removes the tag input and the #710 guard as well, leaving
register_tag as the only dispatch input and two jobs in the file.

Losing the test gate would leave the image build ungated, so the release
build now refuses a release with no InvoiceShelf.zip. A release either
came from the tested pipeline or it gets no images — the updater is
already protected this way, since registration downloads that same asset.
GitHub offers no way to forbid hand-made releases; this is the closest
thing, which is to make them inert.

"Docker" no longer describes a workflow that registers on the updater and
publishes images, so it becomes publish.yaml — matching its trigger and
pairing with release.yaml, which prepares what this distributes. The
recovery instructions in AGENTS.md name this workflow and would have
broken silently, so they move with it.
2026-07-29 18:27:18 +02:00
Darko Gjorgjijoski
7597ddaea7 ci: make tag-triggered releases work, and only publish complete ones (#715)
release.yaml has never run. It listens for "v*" tags while every tag ever
cut is bare — 3.0.0-alpha.1, 2.4.2, 2.4.3-beta.1 — so tagging by the
established convention produced silence, and whoever cuts 3.0.0 would
have hit that first. It now accepts both spellings.

It also hand-copied the release file list, which docker.yaml then rebuilt
via `make clean dist` and uploaded with overwrite: true. The two lists
were identical, so nothing had broken yet, but which zip users received
was decided by job ordering. `make dist` owns the artifact now and the
duplicate is gone.

The release is created as a draft with the package already attached and
published in a separate step, so `release: published` fires only once the
tests have passed and the asset is in place. A failed run leaves no
release at all, rather than a published one nobody can download — which
is what 2.4.2 left behind. Registration can no longer race the upload
either, so docker.yaml drops its build job, and register_release loses
both that dependency and the always() dance it needed to survive the job
being skipped on a manual dispatch.

GitHub's "Latest release" pointer is gated on LATEST_MAJOR, exactly as
docker.yaml gates its moving image tags: a 3.0.0 alpha can no longer
displace 2.4.x as the release users are shown first. Release notes come
from CHANGELOG.md instead of being generated from commits, matching where
the updater already reads them, and a tag with no section fails before
anything is published.

The test job moves to a reusable workflow rather than being written out
in both places — the duplicated file list above is the argument.
2026-07-29 15:51:14 +02:00