ci: put buildah login flags before the registry #3

Merged
aiko merged 1 commit from ci/buildah-login-flag-order into main 2026-08-14 10:51:29 +00:00
Owner

Follow-up to #2, which merged before this fix was pushed — so the branch carried it but main never got it.

The failure

too many arguments, login takes only 1 argument
exit status 125

Older buildah disables interspersed flag parsing on login, so

buildah login <registry> --username x --password-stdin

reads --username, x and --password-stdin as additional positionals and rejects the lot. Newer buildah accepts either order.

The fix

Flags before the registry. Verified both orders parse identically on buildah 1.33.7, so this is correct on old and new alike and does not expire when the runner image updates.

Every other buildah call in the workflow — bud, push, from, run, rm — already had its flags first. login was the only one with a positional ahead of them.

Also

Defaults GITHUB_ACTOR. It is not guaranteed to be populated on this forgejo instance, and an empty username would have been the next failure in line.

Note on updating buildah instead

Worth recording why that is not the fix here. Which buildah version the job gets is decided by the runner's base image, which runs-on: ubuntu-latest resolves through this forgejo instance. Forcing a newer one means either pinning the job's container: — which needs the container runtime that #2 was working around — or adding a third-party repo, and the Kubic repos that used to serve newer buildah are deprecated. Flags-first costs nothing and is version-agnostic.

The diagnostics step added in #2 prints buildah version before login, so the failing run's log already records which version the runner actually carries.

Follow-up to #2, which merged before this fix was pushed — so the branch carried it but `main` never got it. ## The failure ``` too many arguments, login takes only 1 argument exit status 125 ``` Older buildah disables interspersed flag parsing on `login`, so ``` buildah login <registry> --username x --password-stdin ``` reads `--username`, `x` and `--password-stdin` as *additional positionals* and rejects the lot. Newer buildah accepts either order. ## The fix Flags before the registry. Verified both orders parse identically on buildah 1.33.7, so this is correct on old and new alike and does not expire when the runner image updates. Every other `buildah` call in the workflow — `bud`, `push`, `from`, `run`, `rm` — already had its flags first. `login` was the only one with a positional ahead of them. ## Also Defaults `GITHUB_ACTOR`. It is not guaranteed to be populated on this forgejo instance, and an empty username would have been the next failure in line. ## Note on updating buildah instead Worth recording why that is not the fix here. Which buildah version the job gets is decided by the runner's base image, which `runs-on: ubuntu-latest` resolves through this forgejo instance. Forcing a newer one means either pinning the job's `container:` — which needs the container runtime that #2 was working around — or adding a third-party repo, and the Kubic repos that used to serve newer buildah are deprecated. Flags-first costs nothing and is version-agnostic. The diagnostics step added in #2 prints `buildah version` before login, so the failing run's log already records which version the runner actually carries.
Older buildah disables interspersed flag parsing on `login`, so
`buildah login <registry> --username x --password-stdin` reads the flags as
extra positionals and fails with "too many arguments, login takes only 1
argument". Newer buildah accepts either order, so flags-first is correct on
both and does not expire when the runner image updates.

Verified both orders parse identically on buildah 1.33.7, so this is not a
workaround with a shelf life.

Also defaults GITHUB_ACTOR, which is not guaranteed to be set on this forgejo
instance and would otherwise send an empty username.
aiko merged commit 2dad123ea7 into main 2026-08-14 10:51:29 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
mobrule/mobrule-ci!3
No description provided.