fix(review): say when artifacts cannot be listed - #98
Conversation
Listing artifacts needs actions: read; uploading them needs nothing. A repository whose workflow omits the permission therefore publishes a bundle on every run and reads one on none, while the log says only "No stored ... to reuse" — the same line an empty repository prints on its first run. It looks like a permanent cold cache and never explains itself. CodeBoarding-webview is in exactly that state: every review publishes both bundles and every review starts from the base. A denied listing now warns and names the permission, which is the one thing the reader needs to know. A genuinely empty result still prints the notice it printed before. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CodeBoarding reviewStatus: 0 changed components See the full change in CodeBoarding. graph LR
n_Visual_Rendering_Engine["Visual Rendering Engine"]
n_Structural_Diff_Engine["Structural Diff Engine"]
n_Interaction_Orchestrator["Interaction Orchestrator"]
n_Visual_Rendering_Engine -- "Returns rendering metadata and diagram artifacts" --> n_Interaction_Orchestrator
n_Structural_Diff_Engine -- "Provides annotated diff model for visualization" --> n_Visual_Rendering_Engine
n_Interaction_Orchestrator -- "Triggers structural comparison via CLI" --> n_Structural_Diff_Engine
classDef added fill:#1f883d,stroke:#0b5d23,color:#ffffff;
classDef modified fill:#bf8700,stroke:#7d4e00,color:#ffffff;
classDef deleted fill:#cf222e,stroke:#82071e,color:#ffffff,stroke-dasharray:5 3;
|
|
Closing per discussion: near-zero users on the affected versions, and the workflow template now ships Worth recording what the state looks like, since the warning this would have added is now not there to explain it: a job without Checked across the org — 12 of 13 repositories with the review workflow are currently in exactly that state: CodeBoarding, CodeBoarding-webview (fixed on #81, not merged), graph-viewer, vercel, CodeBoarding-vscode, CodeBoarding-DashBoard, CodeBoarding-tests, CodeBoarding-evals, CodeBoarding-wrapper, CodeBoarding-walkthrough, licensing-aws, pytorch The permission is the fix; this was only the diagnosis. Reopen if those workflows are not going to be updated. |
|
Reopening. The premise I accepted was wrong: this is not about users of a previous action version, it is about every workflow written before the template gained the line — which is all existing installs. They also publish two bundles per run against their own storage quota that nothing will ever read, so it costs them twice. Extending it: a log warning only reaches someone already looking. A run in this state will now also say so in the review comment, which is the surface they actually see. |
Found while trying to run an end-to-end test on CodeBoarding-webview.
The symptom
Every review run there prints:
and then, in the same run, publishes both bundles successfully. It looks like a repository that is permanently cold for no reason.
The cause
Listing artifacts requires
actions: read. Uploading requires nothing. The webview's review job grantscontents,pull-requests,issuesandid-token, so it can publish but never look. And because the listing call was|| true, a denial produced the same message as an empty result — the one an empty repository legitimately prints on its first run.So a misconfigured repository pays for a full derivation on every run, publishes bundles nobody will ever read, and has no way to find out.
The fix
A denied listing now warns and names the permission:
A genuinely empty result still prints the notice it always did. Behaviour is otherwise unchanged: reuse remains best-effort and the run derives from the base either way.
test_it_says_why_when_the_listing_is_deniedcovers it. 94 tests pass.Follow-up, not in this PR
CodeBoarding-webview needs
actions: readadded to its review job before any of the reuse works there, and the workflow template the webview generates for users needs the same line — otherwise every repository it onboards lands in this state.🤖 Generated with Claude Code