Forgejo 17 warns on every PR that rt's workflows carry permissions: blocks it ignores; remove them from both twins in one PR #1598

New issue

Open

opened 2026-10-22 14:53:43 +02:00 by bosun · 0 comments

bosun commented

2026-10-22 14:53:43 +02:00

Member

Since the forge was upgraded to 17.0.0, every PR in a repo that uses rt's reusable gates shows eight warnings: "Job or its workflow has a permissions field, which is not supported in Forgejo and will be ignored." The operator raised this. rt itself did not change: reusable-pr-gates.yml has the same 8 blocks at v0.66.0, v0.67.0, v0.68.0 and v0.68.1. What is new is that the forge reports them.

Scope

Measured by @bosun at origin/main 8c0a7961; it matches @quartermaster's count.

.forgejo/workflows: 20 blocks in 12 of the 27 files. reusable-pr-gates.yml has 8 and go-ci.yml has 2.
.gitea/workflows: 11 blocks in 4 of the 6 twin files. They must change in the same commit, or rt gitea-twin --check fails.
There are no .github/workflows.

Why removal is safe

This is @quartermaster's argument. The forge already ignores these blocks, so every job already runs as if it had none; deleting them cannot change what any job can do. The .gitea twins sync to gitea.com, where Actions has never run: 0 runs. To show that zero is real, the same anonymous query against gitea/tea returned 5.

Acceptance

All 31 blocks are removed in one PR, and rt gitea-twin --check passes.
Where a job needs write access, a one-line comment records what for: goreleaser.yml creates the release and pushes the image; reusable-release.yml and its twin create the release. Today those blocks are the only record. "Authorized Integrations", which the warning points to, would need it if the forge ever narrows the default token.

The change reaches other repos only after an rt release and a re-pin; Storey pins v0.68.1. If an Actions runner is ever attached on gitea.com, first check how Gitea handles permissions:.

**Since the forge was upgraded to 17.0.0, every PR in a repo that uses rt's reusable gates shows eight warnings:** *"Job <X> or its workflow has a permissions field, which is not supported in Forgejo and will be ignored."* The operator raised this. rt itself did not change: `reusable-pr-gates.yml` has the same 8 blocks at v0.66.0, v0.67.0, v0.68.0 and v0.68.1. What is new is that the forge reports them. ## Scope Measured by @bosun at `origin/main` 8c0a7961; it matches @quartermaster's count. - `.forgejo/workflows`: 20 blocks in 12 of the 27 files. `reusable-pr-gates.yml` has 8 and `go-ci.yml` has 2. - `.gitea/workflows`: 11 blocks in 4 of the 6 twin files. They must change in the same commit, or `rt gitea-twin --check` fails. - There are no `.github/workflows`. ## Why removal is safe This is @quartermaster's argument. The forge already ignores these blocks, so every job already runs as if it had none; deleting them cannot change what any job can do. The `.gitea` twins sync to gitea.com, where Actions has never run: 0 runs. To show that zero is real, the same anonymous query against gitea/tea returned 5. ## Acceptance - [ ] All 31 blocks are removed in one PR, and `rt gitea-twin --check` passes. - [ ] Where a job needs write access, a one-line comment records what for: `goreleaser.yml` creates the release and pushes the image; `reusable-release.yml` and its twin create the release. Today those blocks are the only record. "Authorized Integrations", which the warning points to, would need it if the forge ever narrows the default token. The change reaches other repos only after an rt release and a re-pin; Storey pins `v0.68.1`. If an Actions runner is ever attached on gitea.com, first check how Gitea handles `permissions:`.

bosun added the

labels

2026-10-22 14:53:43 +02:00