Merge branch 'ci/registry-token-host' into 'main'

Fetch the registry token from the public address, not the runner's See merge request inbuxa/inbuxa-admin!7
Fetch the registry token from the public address, not the runner's
2026-09-21 18:20:30 -07:00 · 2026-09-21 16:48:43 -07:00 · 2026-09-21 23:35:57 +00:00 · 2026-09-21 16:33:30 -07:00 · 2026-09-21 16:31:01 -07:00
2 changed files with 14 additions and 1 deletions
@@ -87,6 +87,19 @@ publish:
      echo "VERSION=$VERSION" > version.env
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
    - docker run --privileged --rm tonistiigi/binfmt --install arm64
+    # The registry hands out push tokens from https://git.coffeylabs.org/jwt/auth,
+    # and buildx fetches them here, in the job, not in its builder. On ci-net
+    # that name is the gitlab container itself (172.30.0.2), which serves
+    # plain HTTP to the runner and nothing on 443, so every push failed at the
+    # last step with "connection refused". The login above works because the
+    # host's daemon does it, and the host resolves the name publicly. So, for
+    # this job only, point the name at its public address the same way. Only
+    # the token request uses it; layers go to the registry's own DNS-only name.
+    - |
+      public="$(nslookup "$CI_SERVER_HOST" 1.1.1.1 2>/dev/null | awk '/^Address: / && $2 !~ /:/ { print $2; exit }')"
+      if [ -z "$public" ]; then echo "Could not resolve $CI_SERVER_HOST publicly" >&2; exit 1; fi
+      echo "$public $CI_SERVER_HOST" >> /etc/hosts
+      echo "$CI_SERVER_HOST -> $public for the registry token"
    - docker buildx create --use --name ci-builder --driver docker-container || docker buildx use ci-builder
  script:
    - . ./version.env
@@ -1,3 +1,3 @@
 {
-  "version": "2026.9.21"
+  "version": "2026.9.21.2"
 }
Author	SHA1	Message	Date
jcoffey-dev	2cd73c6705	Merge branch 'ci/registry-token-host' into 'main' Fetch the registry token from the public address, not the runner's See merge request inbuxa/inbuxa-admin!7	2026-09-21 18:20:30 -07:00
jcoffey-dev	7a455e7b6a	Fetch the registry token from the public address, not the runner's 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.	2026-09-21 16:48:43 -07:00
weekly-release	ff38c7a5e8	Version 2026.9.21.2	2026-09-21 23:35:57 +00:00
jcoffey-dev	0454528e8a	Merge branch 'ci/buildx-host-network' into 'main' Publish with a builder on the host's network See merge request inbuxa/inbuxa-admin!6	2026-09-21 16:33:30 -07:00
jcoffey-dev	9967f9cd7f	Publish with a builder on the host's network 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.	2026-09-21 16:31:01 -07:00