[ivanmilevtues]

Why

A new user sees their map before merging the setup PR, but never one of their own pull requests on it, and they have to sit on the progress page for 5 to 10 minutes because nothing tells them when it is done. Before the setup PR merges, its own pull_request run is the only one GitHub starts for us (comment commands and dispatches need the workflow on the default branch), so both have to happen inside that run.

What changes

On a run whose head branch is codeboarding/setup-action, after the map is uploaded and the review comment posted:

1. Resolve pull requests to preview reads <!-- codeboarding:preview 412,409,401 --> from the setup PR's description through the API (not the event payload, so a list changed while the map was building counts). At most 3; forks, closed PRs and PRs into another branch are skipped with a notice.
2. Preview pull request 1–3 applies each PR's own changes (its merge base to its head, as GitHub's Files tab shows them) to the commit this run analysed and analyses incrementally from the base graph already in hand. Only the PR's own work differs, so other people's commits are never reported as its changes; one that does not apply cleanly is skipped. Each is uploaded as codeboarding-preview-<run>-<attempt>-pr<n>-<head sha> (so the app attributes it without a download), metadata basis: preview, setup_pr, the PR's head_sha. Nothing is posted on those PRs.
3. Tell the setup PR's author the map is ready posts one new comment after the first preview (or after the map, with none). The sticky review comment is an edit by then and edits send no notification; a new comment on their own PR is emailed to the author, who is the person who clicked Generate (the app opens the setup PR with their token). Once per PR, by marker.

The preview names deliberately avoid codeboarding-review-<run>-…: the webview takes the newest artifact with that prefix as the setup PR's own review, so a preview named that way would replace the setup PR's map.

All new steps are continue-on-error. Credentials stay through the previews on a setup PR's run only; the last preview step and the always() cleanup (moved after the previews) remove them. Every other PR's run is unchanged.

Depends on

The webview half (picker that writes the description line, previews shown on PR N's page, per-PR progress) is CodeBoarding/CodeBoarding-webview#227. Until it ships, no setup PR carries the line, so this only adds the ready email.

Tests

python -m unittest discover -s tests: 261 pass. New: tests/test_setup_previews.py (resolution against a stub gh; previews against a real git history where main moved after the PR forked; a conflicting PR skipped; metadata; inlined base) and tests/test_setup_ready_notice.py. tests/test_with_auth.py now allows the head analysis to keep credentials on a setup PR's run only. Protected tests untouched and passing. Not yet run on a live setup PR.

Nothing visible changes in an app; the visible output is the comment text in notify-setup-ready.sh.

🤖 Generated with Claude Code

[codeboarding-review]

CodeBoarding review

Status: 0 changed components (no analysed file changed)

See the full change in CodeBoarding.

graph LR
    n_Action_Workflow_Scripts["Action Workflow Scripts"]
    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;

Loading

_{download artifacts · run 39319276453}