ci: drop permissions blocks Forgejo does not support #18

Merged

geusebio merged 3 commits from ci/drop-unsupported-permissions-blocks into main 2026-08-04 13:02:43 +00:00

Conversation 1 Commits 3 Files changed 5 +343 -26

geusebio commented 2026-08-04 09:39:07 +00:00

Owner

Copy link

Forgejo has no support for the permissions field: it warns about it on every run and then ignores it, so the declared scopes were never actually in effect. Every run was emitting:

Job test or its workflow has a permissions field, which is not supported in
Forgejo and will be ignored. Use Authorized Integrations to grant capabilities
to this job instead.

(and the same for build).

Changes

• build.yml — removed the workflow-level block and the per-job blocks on test and build, the two jobs named in the warnings.
• mirror-baseimages.yml — same treatment. It carried identical blocks and would emit the same warning on its next scheduled run.
• CLAUDE.md — recorded the quirk in the Forgejo Actions list so the blocks don't get reinstated, and corrected the neighbouring anchor bullet, which cited permissions as a field YAML anchors do expand on. That example no longer exists.

Each removal site keeps a short comment pointing at Authorized Integrations as the real mechanism.

Notes

No behaviour change on Forgejo — the blocks were already inert, so this is warning cleanup plus removing a permission model the files implied but never applied.

Worth knowing: if these workflows ever run on real GitHub Actions, the removal would matter. GITHUB_TOKEN would fall back to the repo default rather than the declared scopes, and build wanted packages: write. Given the Forgejo-specific pinning throughout, that isn't a target today.

Verification

Both files parse as YAML. act -n dry-runs clean: build.yml on push, mirror-baseimages.yml on schedule across all 9 matrix legs.

🤖 Generated with Claude Code

Forgejo has no support for the `permissions` field: it warns about it on every run and then ignores it, so the declared scopes were never actually in effect. Every run was emitting: ``` Job test or its workflow has a permissions field, which is not supported in Forgejo and will be ignored. Use Authorized Integrations to grant capabilities to this job instead. ``` (and the same for `build`). ## Changes - **build.yml** — removed the workflow-level block and the per-job blocks on `test` and `build`, the two jobs named in the warnings. - **mirror-baseimages.yml** — same treatment. It carried identical blocks and would emit the same warning on its next scheduled run. - **CLAUDE.md** — recorded the quirk in the Forgejo Actions list so the blocks don't get reinstated, and corrected the neighbouring anchor bullet, which cited `permissions` as a field YAML anchors *do* expand on. That example no longer exists. Each removal site keeps a short comment pointing at Authorized Integrations as the real mechanism. ## Notes No behaviour change on Forgejo — the blocks were already inert, so this is warning cleanup plus removing a permission model the files implied but never applied. Worth knowing: if these workflows ever run on real GitHub Actions, the removal would matter. `GITHUB_TOKEN` would fall back to the repo default rather than the declared scopes, and `build` wanted `packages: write`. Given the Forgejo-specific pinning throughout, that isn't a target today. ## Verification Both files parse as YAML. `act -n` dry-runs clean: `build.yml` on `push`, `mirror-baseimages.yml` on `schedule` across all 9 matrix legs. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

geusebio added 1 commit 2026-08-04 09:39:07 +00:00

ci: drop permissions blocks Forgejo does not support ... e953cc0ebc

Forgejo has no support for the `permissions` field: it warns about it on
every run and then ignores it, so the declared scopes were never in
effect. Remove the workflow-level block and the per-job blocks from both
workflows to silence the warnings and stop the files implying a
permission model that is not applied. Job capabilities come from
Authorized Integrations in the repo settings instead.

Record the quirk in CLAUDE.md, and correct the neighbouring anchor bullet
which cited `permissions` as a field anchors do expand on -- that example
no longer exists.

No behaviour change on Forgejo; the blocks were already inert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

geusebio commented 2026-08-04 09:53:05 +00:00

Author

Owner

Copy link

CI on e953cc0 failed, but the failure is unrelated to this change — the runner ran out of disk.

What happened: run 254 died with 25 no space left on device errors from buildkit, e.g.

#585 ERROR: write /blobs/sha256/5e1ca14d…: no space left on device
#547 ERROR: npm-11.11.0-r0: No space left on device
#467 ERROR: process "/bin/sh -c set -ue apt-get update…" did not complete successfully: exit code: 100

The cascade of failed to copy to tar: io: read/write on closed pipe errors is downstream of the same exhaustion, and the builder then couldn't even be torn down (context deadline exceeded removing the buildx volume).

Why it isn't this PR: the only functional change here is removing permissions blocks that Forgejo already ignores, so it cannot influence what gets built or how much disk it takes. Corroborating: task 35615 on unrelated branch claude/brave-ritchie-86fd3d failed at the same moment, and task 35612 was building concurrently. Three full-matrix builds sharing one runner's btrfs backing store exhausted it.

Not re-run yet: this Forgejo version has no rerun API (POST /actions/runs/254/rerun → 404), and the competing build was still running, so an immediate retry would likely hit the same wall. Needs either a re-run from the web UI once the runner is quiet, or a push to this branch to retrigger.

CI on `e953cc0` failed, but the failure is unrelated to this change — the runner ran out of disk. **What happened:** [run 254](https://git.grey.ooo/Grey.ooo/docker/actions/runs/254) died with 25 `no space left on device` errors from buildkit, e.g. ``` #585 ERROR: write /blobs/sha256/5e1ca14d…: no space left on device #547 ERROR: npm-11.11.0-r0: No space left on device #467 ERROR: process "/bin/sh -c set -ue apt-get update…" did not complete successfully: exit code: 100 ``` The cascade of `failed to copy to tar: io: read/write on closed pipe` errors is downstream of the same exhaustion, and the builder then couldn't even be torn down (`context deadline exceeded` removing the buildx volume). **Why it isn't this PR:** the only functional change here is removing `permissions` blocks that Forgejo already ignores, so it cannot influence what gets built or how much disk it takes. Corroborating: task 35615 on unrelated branch `claude/brave-ritchie-86fd3d` failed at the same moment, and task 35612 was building concurrently. Three full-matrix builds sharing one runner's btrfs backing store exhausted it. **Not re-run yet:** this Forgejo version has no rerun API (`POST /actions/runs/254/rerun` → 404), and the competing build was still running, so an immediate retry would likely hit the same wall. Needs either a re-run from the web UI once the runner is quiet, or a push to this branch to retrigger.

geusebio referenced this pull request 2026-08-04 09:56:51 +00:00

ci: only rebuild the images a change actually affects #20

geusebio added 1 commit 2026-08-04 09:57:30 +00:00

ci: retrigger CI ... dba581f8b3

Run 254 failed on e953cc0 with `no space left on device`: three
full-matrix builds shared the runner's btrfs store and exhausted it.
Unrelated to the change on this branch, which only removes `permissions`
blocks Forgejo already ignores. This Forgejo has no rerun API, so an
empty commit is the way to retrigger.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

geusebio added 2 commits 2026-08-04 13:00:38 +00:00

ci: only rebuild the images a change actually affects ... 10f68383f5

The build was spending ~30 minutes rebuilding every image on every push,
and the test job another 6-26. Measuring the job logs showed the cost is
package downloads, not CPU: dotnet-10 takes 1191s on native amd64 versus
1288s on arm64 under QEMU, and the gaps sit between individual apk
installs. Most of that work is for images the commit never touched.

Scope each push to the images whose inputs changed, and add a Tuesday
04:00 run that still builds everything, so images nothing depends on --
dotnet above all, ~20 minutes on its own -- keep getting rebuilt against
current upstream packages.

changed-targets derives the graph from the Dockerfiles themselves
(INCLUDE ./x, FROM ./x#stage, COPY ./fs/y) and reads target names back
out of `bake --print` and `compose config`, so adding an image needs no
change to it and the mapping cannot drift. Files that cannot be scoped
that way -- the bake file, the test compose files, the scripts,
.github/ -- force a full build, as does an unknown or unreachable base
commit. Getting this wrong should cost time, never correctness.

./test grows TEST_SERVICES. It builds a generated test-subset aggregator
rather than an override file because compose merges depends_on by union,
so an override can only ever add services to `test`, never narrow it.

Also fix the concurrency group. `github.head_ref` is only set for
pull_request events, so on a push it fell back to the always-unique
run_id and cancel-in-progress never cancelled anything. The weekly run
gets its own lane so a Tuesday-morning push cannot cancel the only build
that covers every image.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Merge pull request 'ci: only rebuild the images a change actually affects' (#20) from ci/scope-builds-to-changed-images into ci/drop-unsupported-permissions-blocks ... 6143c6ce20

Reviewed-on: #20

geusebio force-pushed ci/drop-unsupported-permissions-blocks from 6143c6ce20 to 67be71e6c1 2026-08-04 13:01:10 +00:00 Compare

geusebio merged commit 9e32a9b213 into main 2026-08-04 13:02:43 +00:00

geusebio referenced this pull request from a commit 2026-08-04 13:02:45 +00:00

Merge pull request 'ci: drop permissions blocks Forgejo does not support' (#18) from ci/drop-unsupported-permissions-blocks into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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

Grey.ooo/docker!18

No description provided.