lint-python.yaml: pull-requests permission from #184 causes startup_failure in all downstream QA callers

Metadata

Project: starflow
Number: #185
Type: issue
State: open
Author: lengau
Labels: —
Created: 2026-09-22 05:11 PM UTC
Updated: 2026-09-22 05:11 PM UTC
Closed: —

Current evaluation

PR #184's pull-requests: read in lint-python.yaml breaks every downstream QA caller with startup_failure, since reusable workflows can only narrow caller permissions. craft-parts/craft-application QA broken; untriaged.

Suggested action: needs triage

Reason: The report is a well-evidenced regression with a pinpointed root cause: it cites #184 as the change that 'added pull-requests: read to the files job's permissions' and correctly identifies GitHub's rule that 'a called workflow may only use a subset of the caller's granted permissions,' supported by run IDs (35741616520, 35736296111, 35743271749) that fail after 2026-09-21 20:17 UTC while the same PR's QA ran jobs normally before, plus actionlint clearing the caller files. Impact is high because a shared reusable workflow consumed via @main breaks QA for all downstream repos (craft-parts, craft-application). However, the issue has no labels, no assignee, and zero comments since filing10 days ago, so it shows no sign of maintainer categorisation — needs_triage rather than keep_open. Fix choice is non-trivial: all three proposed options have costs (revert reopens #183, whose summary notes the pull-requests: read proposal 'remains unverified'; the gated-input and coordinated-rollout options require breaking-change handling across callers). Confidence is capped because I could not verify the current lint-python.yaml contents or confirm whether any downstream rollout or revert has since landed.

Evaluated by: mr-cal-bot

Impact: 72 Quick Win: 26 Complexity: 58 Confidence: 76 Actionability: 85

Issue body

🤖 [BEEP BOOP, A BOT WROTE THIS ISSUE - Kimi K3, Copilot CLI] I'm a robot filing this issue as a side-effect of research done while running the `update-starbase` skill on canonical/craft-parts (see canonical/craft-parts#1728). A human has reviewed and approved filing this issue. ## Problem Since #184 ("fix: widen permissions on filter step") merged on 2026-09-21 (~20:17 UTC), every `QA` workflow run in downstream repositories that call `canonical/starflow/.github/workflows/lint-python.yaml@main` fails immediately with `startup_failure` (run duration ~1s, zero jobs created, "This run likely failed because of a workflow file issue"). The change added `pull-requests: read` to the `files` job's `permissions` in `lint-python.yaml`. Callers that invoke the reusable workflow without granting `pull-requests: read` themselves can no longer start the workflow, since a called workflow may only use a subset of the caller's granted permissions. ## Evidence - canonical/craft-parts: QA runs [35741616520](https://github.com/canonical/craft-parts/actions/runs/35741616520), 35736296111, and 35743271749 — all `startup_failure` after 2026-09-21 20:17 UTC; the same PR's QA ran jobs normally before that timestamp. - canonical/craft-application: the three most recent QA runs (2026-09-22) are all `startup_failure`. - `actionlint` reports no issues with the downstream workflow files, and the same caller configuration worked until #184 merged. ## Possible fixes - Revert #184 and find another way to address #183 (e.g., requiring private-repo callers to grant `pull-requests: read` explicitly, documented as a breaking change), or - Gate the permission need behind an input so public repos keep working, or - Coordinate a downstream rollout where every caller adds `pull-requests: read` to the calling job first (breaking-change process). Happy to test a fix against the craft-parts QA workflow once available.

Evaluation history

Date	Model	Scores	Action	Summary
2026-10-02 08:44 PM UTC	stealth/space-bunny-alpha	Impact: 72 Quick Win: 26 Complexity: 58 Confidence: 76 Actionability: 85	needs triage	PR #184's pull-requests: read in lint-python.yaml breaks every downstream QA caller with startup_failure, since reusable workflows can only narrow caller permissions. craft-parts/craft-application QA broken; untriaged.
2026-09-25 10:21 AM UTC	stealth/space-bunny-alpha	Impact: 78 Quick Win: 37 Complexity: 46 Confidence: 93 Actionability: 89	needs triage	lint-python.yaml's new pull-requests: read requirement is breaking reported craft-parts and craft-application reusable QA calls with startup_failure; unlabelled and awaiting maintainer triage.
2026-09-22 06:47 PM UTC	qwen/qwen3.6-35b-a3b	Impact: 55 Quick Win: 33 Complexity: 25 Confidence: 75 Actionability: 80	needs triage	starflow's lint-python.yaml PR #184 added pull-requests: read permission, causing startup_failure in downstream QA workflows that don't grant it. Awaiting maintainer triage.

Update history

Date	Change
2026-09-22 05:11 PM UTC	created

Related work

Caused By: starflow#184 (confidence 95%)
Merged PR 'fix: widen permissions on filter step' added pull-requests: read to the files job, which called workflows cannot widen beyond the caller's grant.
Related To: starflow#183 (confidence 88%)
The private-repo filter failure #184 was fixing; reverting #184 reopens it, and its summary records the pull-requests: read approach as unverified.

Related issues

No related issues found above the similarity threshold.