bump.yml: a missing commitizen-bot grant on a private repo surfaces as a bare git 128, not a permissions error #25

New issue

Open

opened 2026-08-20 08:36:37 +00:00 by gravityfargo · 0 comments

gravityfargo commented

2026-08-20 08:36:37 +00:00

Owner

What happens

bump.yml's checkout takes the bot PAT whenever Infisical resolves it:

uses: actions/checkout@v7
with:
    token: ${{ env.REPOSITORY_ACCESS_TOKEN || github.token }}
    fetch-depth: 0

REPOSITORY_ACCESS_TOKEN is the commitizen-bot PAT from /forgejo-users/commitizen-bot. It wins the ||, so the github.token fallback never applies in practice. On a private repo where commitizen-bot is not a collaborator, the bot cannot see the repo at all and the fetch dies:

[command]/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules origin ...
remote: Repository not found
fatal: repository 'https://code.modernleft.org/<owner>/<repo>/' not found
The process '/usr/bin/git' failed with exit code 128

Retried at 10s and 16s, then the job fails.

Why the message misleads

"Repository not found" reads as a typo in the repo name, and the repo plainly exists — every other job in the same run checked it out seconds earlier using the default Actions token. Nothing in the failure names the actual cause, which is that the bot lacks read access.

Observed on gravityfargo/pyvikunja run 4609, job bump-version. Granting commitizen-bot write on the repo fixed it.

Suggested fix

When REPOSITORY_ACCESS_TOKEN is set and the checkout 404s, fail with a named error saying the bot is not a collaborator on the repo, rather than letting the bare git 128 through. A pre-checkout probe against the repo endpoint with the bot token would catch it before the retries.

gravityfargo/templates issue #38 covered the documentation half — common-versioning/TEMPLATE.md now names the grant as an adoption prerequisite for private repos (templates e2cf1b6). This issue is the diagnostic half.

## What happens `bump.yml`'s checkout takes the bot PAT whenever Infisical resolves it: ```yaml uses: actions/checkout@v7 with: token: ${{ env.REPOSITORY_ACCESS_TOKEN || github.token }} fetch-depth: 0 ``` `REPOSITORY_ACCESS_TOKEN` is the `commitizen-bot` PAT from `/forgejo-users/commitizen-bot`. It wins the `||`, so the `github.token` fallback never applies in practice. On a **private** repo where `commitizen-bot` is not a collaborator, the bot cannot see the repo at all and the fetch dies: ``` [command]/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules origin ... remote: Repository not found fatal: repository 'https://code.modernleft.org/<owner>/<repo>/' not found The process '/usr/bin/git' failed with exit code 128 ``` Retried at 10s and 16s, then the job fails. ## Why the message misleads "Repository not found" reads as a typo in the repo name, and the repo plainly exists — every other job in the same run checked it out seconds earlier using the default Actions token. Nothing in the failure names the actual cause, which is that the bot lacks read access. Observed on `gravityfargo/pyvikunja` run 4609, job `bump-version`. Granting `commitizen-bot` write on the repo fixed it. ## Suggested fix When `REPOSITORY_ACCESS_TOKEN` is set and the checkout 404s, fail with a named error saying the bot is not a collaborator on the repo, rather than letting the bare git 128 through. A pre-checkout probe against the repo endpoint with the bot token would catch it before the retries. ## Related `gravityfargo/templates` issue #38 covered the documentation half — `common-versioning/TEMPLATE.md` now names the grant as an adoption prerequisite for private repos (templates e2cf1b6). This issue is the diagnostic half.

No labels

No milestone

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

ModernLeft/commitizen-ci#25

No description provided.

Rows
Columns