The builder on the host's network (the last change here) didn't help: the
next publish failed exactly as before. Looking on the host showed why.
Both builders resolve git.coffeylabs.org publicly; the token isn't fetched
by the builder at all. buildx fetches registry tokens on the client side,
in the job container, and on ci-net the name git.coffeylabs.org belongs to
the gitlab container itself (172.30.0.2) -- which is how the runner clones
over plain HTTP, and which has nothing on 443. So every push asked
https://git.coffeylabs.org/jwt/auth for a token and was refused. The login
before it worked because the host's daemon does the login, and the host
resolves the name publicly.
For the publish job only, the name now points at its public address in the
job's /etc/hosts, looked up from a public resolver, as the host sees it.
/etc/hosts wins over Docker's DNS, and nothing else in the job is affected:
the checkout is done, and image layers go to the registry's own DNS-only
name, not this one. The builder goes back to the shared ci-builder; its
network was never the problem.
The lookup and the /etc/hosts write were tried in the job's own image
(docker:28-cli, same digest): it picks the first public IPv4 address and
getent then returns it.
The first release's image never reached the registry. Both platforms
built, then the push failed:
failed to fetch oauth token: Post "https://git.coffeylabs.org/jwt/auth":
dial tcp 172.30.0.2:443: connect: connection refused
buildx's docker-container builder is a container of its own on the host's
daemon, and it does the push, token and all. On the network it was
created on, git.coffeylabs.org resolves to an internal address with
nothing listening on 443. The job's own `docker login` worked because it
goes through the host daemon, which resolves the name publicly.
ihasmail's publish failed the same way this morning (job 513), so this is
the runners, not this pipeline.
The builder now runs on the host's network, so it resolves the name as
the login does. Only the token request goes to git.coffeylabs.org; image
layers still go to registry.coffeylabs.org, the registry's DNS-only name.
It gets a new name, ci-builder-host: `ci-builder` is a long-lived
container shared between jobs, and `create || use` would keep reusing it
on its old network.
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.
Ports .github/workflows/ci.yml after the GitHub account was suspended and
Actions stopped being reachable. Same checks, same order, with the image
pinned by digest in place of the workflow's SHA-pinned actions.
cleanup.yml is not ported: it pruned GHCR through an action, and GitLab
keeps that as a container registry cleanup policy on the project rather
than as a pipeline. publish.yml and release.yml are larger and follow
separately.
The Actions workflows stay in the tree as the reference.
.gitignore blanket-ignores dotfiles, so .gitlab-ci.yml is negated there the
same way .github already is.
jcoffey-dev