fix(ci): image pushes read the registry secrets that exist (#1275) #1306

2026-08-18T04:50:47Z

jarvis commented

2026-08-18 04:50:47 +00:00

All kaniko image steps referenced from_secret gitea_username/gitea_password, which do not exist at repo level; the repo instead carries unused REGISTRY_USERNAME/REGISTRY_PASSWORD secrets. Every image push therefore failed at kaniko's push-permission check - measured on 2482 and 2488 (build-gateway), and the same auth gap is documented in ci.yml's step-level pi-install comment re ci-base rebuilds being blocked. This rewires all six references to the REGISTRY_* secrets that exist. Diagnostic by design: if the creds are valid, gated next push pipelines go fully green (verify -> build -> npm -> gateway image); if invalid, the error becomes an explicit 401 - unambiguous either way. Authored inline by the dispatching seat (one-line config fix under time pressure); fargo/fred please review. - topher (jarvis principal)

jarvis added 1 commit 2026-08-18 04:50:48 +00:00

fix(ci): image pushes read the registry secrets that exist (#1275 )

ci/woodpecker/pr/ci Pipeline was successful

Details

e19013ed5e

All kaniko image steps (publish.yml build-gateway/build-ci-base/build-*
and ci-image.yml build-ci-base) referenced from_secret: gitea_username /
gitea_password - which do not exist at repo level - while the repo
carries unused REGISTRY_USERNAME/REGISTRY_PASSWORD secrets. Result: every
image push fails at kaniko's push-permission check (measured: 2482 and
2488 build-gateway 'error checking push permissions'; the same auth gap
is documented in ci.yml's step-level pi install comment re ci-base).

Rewire all six references to the REGISTRY_* secrets that exist. If those
credentials are valid, next push pipelines go fully green behind the new
verify gate; if not, the failure moves to an explicit 401 - either way
the ambiguous permission error resolves into a known state.

fred approved these changes 2026-08-18 04:53:08 +00:00

fred left a comment

APPROVE — @fred, sb-it-1-dt. Head e19013e. Mechanically complete, cannot regress, and corroborated by evidence you did not cite. Two findings below that matter more than the rename itself.

The change is complete, and I counted rather than trusted

files touched            2   (.woodpecker/ci-image.yml, .woodpecker/publish.yml)
from_secret: gitea_*     8 removed
from_secret: REGISTRY_*  8 added
total +/- lines         16   (nothing in this diff is anything but a secret name)
gitea_username|password remaining at head:  ci.yml 0, ci-image.yml 0, publish.yml 0

The PR body says "six references". It is eight — four pairs, one in ci-image.yml and three in publish.yml. The change is right; the count in the description is not, and someone will reconcile that later at cost.

publish.yml still carries two from_secret: gitea_token refs at :126 and :182. Those are correctly left alone — different secret, and 2488's green publish-next-npm is positive proof it exists and works. Worth stating explicitly so nobody "finishes the job" by renaming those too.

Corroboration you have that you did not cite

.woodpecker/ci.yml:141-142, written by whoever hit this earlier: "Step-level install because ci-base image publishes are currently blocked on registry auth; fold into Dockerfile.ci once…" That is independent, contemporaneous documentation of the same registry auth gap, from a different author at a different time. It is stronger support for the diagnosis than the pipeline numbers, because nobody wrote it while trying to prove this point.

Why I can approve without verifying which secrets exist

I did not verify that REGISTRY_USERNAME/REGISTRY_PASSWORD exist or carry push permission — that needs a Woodpecker admin read I am not reaching for. I do not need it, because this change cannot regress anything: today's refs resolve to secrets that do not exist, so REGISTRY_USER/REGISTRY_PASS arrive empty and kaniko fails its push-permission check. The worst case after this merge is identical to the status quo. Best case is green, and the middle case is an explicit 401. Your "diagnostic by design" framing is accurate and it is the right property for a change like this.

Finding 1 — this PR's green check cannot observe this change either. Third one tonight.

publish.yml's top-level when is branch: [main, next], event: [push, manual, tag] — it does not run on pull_request at all. And ci.yml:21 states outright that from_secret is blocked on pull_request events. So pipeline 2492 has two independent reasons it cannot exercise a single line of this diff.

That is #1304, #1306, and (I suspect) #1302 in one night: PRs whose changed property no check on the PR can see. The gate is working; what is missing is any signal distinguishing "green because it passed" from "green because it never looked". Worth a card of its own — a merge-time note naming which pipeline will actually exercise the change would cost one line and close it.

Finding 2 — only ONE of the three rewired publish.yml steps gets validated by the merge

This is the one I would not want you to discover later:

:270 build-gateway     when: *image_build_when       includes  push -> next   (no path exclude)  -> RUNS on merge
:306 build-appservice  when: *main_image_build_when  tag, or push -> main only                   -> does NOT run
:333 build-web         when: *main_image_build_when  tag, or push -> main only                   -> does NOT run

So merging to next exercises the build-gateway rewire and neither of the other two. Worse, main_image_build_when carries path: exclude: ['.woodpecker/**'] — so a commit touching only .woodpecker/ files can never trigger those two steps on main either. A future "same fix, verify it on main" commit of this shape would be excluded by its own path filter and report nothing, which reads exactly like success.

Nothing to change in this PR. But when this goes green on next, the honest claim is "the gateway image rewire is validated" — not "the registry secrets are fixed." Appservice and web stay unvalidated until a real content-bearing push to main or a tag.

Scope

I read both changed files in full at head, enumerated every from_secret in all three pipeline configs, and traced the when anchors. I did not inspect the kaniko step bodies beyond the environment blocks, did not verify secret existence or permissions, and ran nothing — there is nothing here I can run.

Approving. Merge it; the diagnostic is worth more than more analysis.

APPROVE — @fred, sb-it-1-dt. Head `e19013e`. Mechanically complete, cannot regress, and corroborated by evidence you did not cite. Two findings below that matter more than the rename itself. ## The change is complete, and I counted rather than trusted ``` files touched 2 (.woodpecker/ci-image.yml, .woodpecker/publish.yml) from_secret: gitea_* 8 removed from_secret: REGISTRY_* 8 added total +/- lines 16 (nothing in this diff is anything but a secret name) gitea_username|password remaining at head: ci.yml 0, ci-image.yml 0, publish.yml 0 ``` **The PR body says "six references". It is eight** — four pairs, one in `ci-image.yml` and three in `publish.yml`. The change is right; the count in the description is not, and someone will reconcile that later at cost. `publish.yml` still carries two `from_secret: gitea_token` refs at :126 and :182. Those are correctly left alone — different secret, and 2488's green `publish-next-npm` is positive proof it exists and works. Worth stating explicitly so nobody "finishes the job" by renaming those too. ## Corroboration you have that you did not cite `.woodpecker/ci.yml:141-142`, written by whoever hit this earlier: *"Step-level install because ci-base image publishes are currently blocked on registry auth; fold into Dockerfile.ci once…"* That is independent, contemporaneous documentation of the same registry auth gap, from a different author at a different time. It is stronger support for the diagnosis than the pipeline numbers, because nobody wrote it while trying to prove this point. ## Why I can approve without verifying which secrets exist I did **not** verify that `REGISTRY_USERNAME`/`REGISTRY_PASSWORD` exist or carry push permission — that needs a Woodpecker admin read I am not reaching for. I do not need it, because **this change cannot regress anything**: today's refs resolve to secrets that do not exist, so `REGISTRY_USER`/`REGISTRY_PASS` arrive empty and kaniko fails its push-permission check. The worst case after this merge is identical to the status quo. Best case is green, and the middle case is an explicit 401. Your "diagnostic by design" framing is accurate and it is the right property for a change like this. ## Finding 1 — this PR's green check cannot observe this change either. Third one tonight. `publish.yml`'s top-level `when` is `branch: [main, next], event: [push, manual, tag]` — it does not run on pull_request at all. And `ci.yml:21` states outright that `from_secret` **is blocked on pull_request events**. So pipeline 2492 has two independent reasons it cannot exercise a single line of this diff. That is #1304, #1306, and (I suspect) #1302 in one night: PRs whose changed property no check on the PR can see. The gate is working; what is missing is any signal distinguishing "green because it passed" from "green because it never looked". Worth a card of its own — a merge-time note naming which pipeline will actually exercise the change would cost one line and close it. ## Finding 2 — only ONE of the three rewired publish.yml steps gets validated by the merge This is the one I would not want you to discover later: ``` :270 build-gateway when: *image_build_when includes push -> next (no path exclude) -> RUNS on merge :306 build-appservice when: *main_image_build_when tag, or push -> main only -> does NOT run :333 build-web when: *main_image_build_when tag, or push -> main only -> does NOT run ``` So merging to `next` exercises the `build-gateway` rewire and neither of the other two. Worse, `main_image_build_when` carries `path: exclude: ['.woodpecker/**']` — so a commit touching **only** `.woodpecker/` files can never trigger those two steps on `main` either. A future "same fix, verify it on main" commit of this shape would be excluded by its own path filter and report nothing, which reads exactly like success. Nothing to change in this PR. But when this goes green on `next`, the honest claim is *"the gateway image rewire is validated"* — not *"the registry secrets are fixed."* Appservice and web stay unvalidated until a real content-bearing push to `main` or a tag. ## Scope I read both changed files in full at head, enumerated every `from_secret` in all three pipeline configs, and traced the `when` anchors. I did not inspect the kaniko step bodies beyond the environment blocks, did not verify secret existence or permissions, and ran nothing — there is nothing here I can run. Approving. Merge it; the diagnostic is worth more than more analysis.

jarvis merged commit 5c5a25e4de into next

2026-08-18 05:02:24 +00:00

fred referenced this pull request

2026-08-18 05:02:41 +00:00

test(ri-050): RI-1-002 publish-gate negative controls (#1275) #1305

jarvis referenced this pull request

2026-08-18 05:44:07 +00:00

Release integrity workstream for alpha 0.0.50 (RI-050) #1275

jarvis referenced this pull request

2026-08-18 07:44:50 +00:00

Release integrity workstream for alpha 0.0.50 (RI-050) #1275

Sign in to join this conversation.