CI: Grant issues read to the reusable workflows

[ModeSevenIndustrialSolutions]

Every pull request is currently failing to start Python Build/Test

main is broken, and quietly. Found while rebasing #393.

python-workflows v0.3.1 added a permission request to its jobs:

      issues: read  # Read maintainer-approved CVE bypass issues

A called workflow cannot hold a permission the caller has not granted. Neither caller in this repository granted issues: read, so the run fails at startup, before any job exists.

Workflow	requests	this repo grants
python-workflows/build-test.yaml@v0.3.1	contents: read, pull-requests: read, issues: read	contents: read, pull-requests: read
python-workflows/build-test-release.yaml@v0.3.1	contents: read/write, id-token: write, attestations: write, issues: read	contents: write, id-token: write, attestations: write

Why nobody noticed

The failure mode is close to invisible:

Python Build/Test    completed    startup_failure
jobs: 0

There is no failing job to click into, no annotation naming the cause, and startup_failure produces no check run at all — so build-test / Python Tests (3.11–3.14), Python Audit, Python Build, Generate SBOM and Grype Audit SBOM simply vanish from the checks list rather than turning red. A PR looks green because the checks that would have failed are absent.

Confirmed across every branch pushed since the bump landed:

fix/typer-click-split    a4c6c6b3  startup_failure
fix/mypy-tests           9134ad28  startup_failure
fix/credential-memo      efe6afd7  startup_failure
fix/open-issues          320781eb  startup_failure
dependabot/uv/ruff-0.16.4        bfd62d19  success   <- ran before the bump merged
chore/license-regular-file       bcc3a06e  success   <- ran before the bump merged

The two successes predate the pin bump, which is why the dependabot PR that introduced it went in clean.

build-test-release.yaml has the same gap, so releases are affected too — that one has not been exercised yet because it runs on tag.

What I ruled out first

Rather than guess from the name, I eliminated the other causes of startup_failure:

commit 23636ccc exists in python-workflows          -> HTTP 200
build-test.yaml exists at that SHA                  -> HTTP 200
audit_permit_fail input still accepted at v0.3.1    -> YES

The reference resolves and the input is still valid. Diffing the job-level permissions: blocks between the old and new pins isolated the one change that matters:

OLD requests: ['contents: read', 'pull-requests: read']
NEW requests: ['contents: read', 'issues: read', 'pull-requests: read']

The change

Two lines, one per caller. Nothing else.

Also drops two comments that read # Pinned to python-workflows v0.1.0 release commit and v0.1.1 while sitting beside a pin annotated v0.3.1 — neither survived a version bump, so the annotation on the uses: line is the only record worth keeping.

On verifying this

This PR cannot exercise the fix itself. build-test.yaml filters '!.github/**', and this change touches nothing else, so Python Build/Test will not appear on this PR at all. Its absence here is the path filter, not the bug.

I tried to close that gap and could not, so stating it plainly rather than implying otherwise:

• Dispatched Python Build/Test via workflow_dispatch on the fork, against this branch and against an unfixed branch as a control. Both accepted (HTTP 204) and both sat queued indefinitely with 0 jobs — the fork has no runners, so the A/B was inconclusive and the runs were left to expire.
• The diagnosis itself is empirical: the permission diff above, plus ruling out the reference and input causes.
• The fix follows from GitHub's documented rule that a called workflow cannot exceed the permissions its caller grants.

Definitive confirmation will come from the first PR after this merges that touches a non-.github path — #393 is already rebased onto current main and changes tests/, so it will show build-test jobs or it will not.

Note on scope and urgency

Raised straight off main rather than folded into the stack, because main itself is broken and this unblocks every PR in the repository, not only mine.

This is not what blocks #393. The required checks are only DCO and pre-commit.ci - pr, both of which pass; build-test is not required. #393 is blocked solely on its dismissed approval, which the rebase onto current main addresses separately.

[Copilot]

🟢 Approval recommended

Pull request overview

Grants reusable Python workflows the permissions required to start successfully.

Changes:

• Adds issues: read to build/test and release workflows.
• Removes outdated pin comments.

File summaries

File	Description
.github/workflows/build-test.yaml	Grants issue-read access to CI.
.github/workflows/build-test-release.yaml	Grants issue-read access to releases.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.