[PR] fix(dev): grant the bump workflow's calling jobs the permissions their callees need [magpie]

["potiuk (via GitHub)" <gi...@apache.org>]

potiuk opened a new pull request, #1237:
URL: https://github.com/apache/magpie/pull/1237

   ## Summary
   
   - **The workflow does not start:**
   
     ```text
     The nested job 'prek' is requesting 'contents: read',
     but is only allowed 'contents: none'.
     ```
   
     A called workflow's jobs may request at most what the **calling** job was granted, and `permissions: {}` at the top of `bump-dev-version.yml` grants the four `uses:` jobs nothing at all.
   - **Each calling job now carries the permissions its callee declares** — `contents: read` for `prek`, `tests` and `rat`, plus `actions: read` for `zizmor`, whose API-backed audits need it.
   - **Also fixes a candidate-branch leak** found while auditing the rest of the file for the same class of problem.
   
   ## Type of change
   
   - [ ] Skill change (`.claude/skills/<name>/`) — eval fixtures updated below
   - [ ] Tool / bridge contract (`tools/<system>/*.md`)
   - [ ] Python package (`tools/*/` with `pyproject.toml`)
   - [ ] Groovy reference impl
   - [ ] Cross-cutting (RFC, AGENTS.md, sandbox, privacy-LLM)
   - [ ] Documentation (`docs/`, `README.md`, `CONTRIBUTING.md`)
   - [ ] Project template (`projects/_template/`)
   - [x] CI / dev loop (`prek`, workflows, validators)
   - [ ] Other:
   
   ## Test plan
   
   - [ ] `prek run --all-files` passes
   - [ ] For Python packages touched: `uv run pytest` / `ruff check` / `mypy` passes
   - [ ] For Groovy bridges touched: command-line invocation tested end-to-end
   - [ ] For skill changes: eval suite passes for the affected skill
   - [ ] For skill *behaviour* changes: a new or updated eval fixture is included in this PR
   - [x] Other:
     - Each calling job's grant was read off its callee's declared job permissions rather than guessed: `pre-commit.yml` → `contents: read`; `tests.yml` → `contents: read` (`members`, `pytest`); `rat.yml` → `contents: read`; `zizmor.yml` → `contents: read` + `actions: read`.
     - `grep` confirms these four are **every** reusable-workflow call in the repository; nothing else `uses:` a local workflow.
     - Audited every remaining job for the same class of defect: `prepare` has both `actions/checkout` and `setup-uv` for the `uv` and `gh` it runs; `open-pr` and `cleanup` use only `gh` and need neither.
     - `zizmor --persona regular` clean across all workflows; `prek` clean.
   
   ⚠️ **Still unproven end to end.** `workflow_dispatch` runs whatever is on `main`, so the next dispatch after this merges is the first that can reach the jobs at all. This is the third parse/permission blocker in a row; I would expect to iterate again rather than assume this is the last.
   
   ## RFC-AI-0004 compliance
   
   - [ ] **HITL** — any new mutation is gated on explicit user confirmation
   - [x] **Sandbox** — no new host access.
   - [ ] **Vendor neutrality** — placeholders used in all skill / tool prose
   - [ ] **Conversational + correctable** — agentic-override path documented if behaviour is adopter-tunable
   - [x] **Write-access discipline** — grants mirror the callee exactly rather than widening.
   - [ ] **Privacy LLM** — private content does not reach a non-approved LLM
   
   ## Linked issues
   
   Follow-up to #1236.
   
   ## Notes for reviewers
   
   - **Mirroring, not `read-all`.** It would be shorter to give each calling job a blanket read scope. Each block instead lists exactly what its callee declares, because the calling job's grant is the ceiling on what a called check can reach — a blanket grant here would silently widen that ceiling for every check, and the next person to add a job to one of those workflows would inherit the wider scope without choosing it.
   - **The branch leak.** `prepare` published its `branch` output at the *end* of the step, after the commit mutation. The branch is created before the mutation, so a failed mutation left it created but unnamed in `needs`, and `cleanup`'s `if [[ -n "$BRANCH" ]]` guard skipped it — leaking a branch on precisely the failure that creates one. The output now lands immediately after the ref is created.
   - **Worth considering separately:** this is the third failure that only surfaced on a real dispatch, because a `workflow_dispatch` workflow cannot be exercised before it is on `main`. A static check that validates each reusable-workflow call against its callee's declared job permissions would have caught this one locally. I have not built it here — say the word if it is wanted.
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(dev): grant the bump workflow's calling jobs the permissions their callees need [magpie]

["potiuk (via GitHub)" <gi...@apache.org>]

potiuk merged PR #1237:
URL: https://github.com/apache/magpie/pull/1237


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org