Ports release.yml and publish.yml, the two workflows left behind when the
GitHub account was suspended; nothing has released INBUXA Admin since.
weekly-release keeps release.yml's decision unchanged: on a schedule that
sets RELEASE_WEEKLY=1, count the commits on main since the newest published
release, stop if there are none, and otherwise pick today's version
(YYYY.M.D, .2 and on for a second release in a day), commit it to main in
inbuxa-version.json and cut the release at that commit. DRY_RUN=1 stops
after the decision.
What changes is how it writes. GitHub's job pushed the bump with
GITHUB_TOKEN; here the bump goes through the commits API with RELEASE_TOKEN,
and last_commit_id pins it to the commit the job counted from, so a main
that moved underneath makes the job fail rather than release something the
notes don't describe. The release and its tag go through the releases API
with the same token, which as an ordinary push starts a tag pipeline --
replacing publish.yml's workflow_call, which only existed because a
GITHUB_TOKEN release raises no event.
publish runs in that tag pipeline, after the build job has built and
tested the tag again. It pushes a two-architecture image (arm64 under QEMU,
as ihasmail's does) to the project registry,
registry.coffeylabs.org/inbuxa/inbuxa-admin, tagged with the version and
latest. Only date tags publish, not the inherited v1.0.x, and a tag whose
commit's inbuxa-version.json says anything else is refused, so an image
never reports a version other than its tag.
Tag lookups use git show-ref, after ihasmail's port found rev-parse
--verify reading some tag names as describe output on the git in these
images.
Needs, on the project: a RELEASE_TOKEN variable (project access token,
Maintainer, api scope, protected and masked) whose role may push to main,
and a pipeline schedule on main, Mondays 09:37 UTC, setting
RELEASE_WEEKLY=1.
jcoffey-dev