Add per-PR Worker Preview deploys - #231
Conversation
![ask-bonk[bot]](https://avatars.githubusercontent.com/in/2454580?s=60&v=4){kind=small}
|
|
||
| const stale: { name: string; reasons: string[] }[] = []; | ||
| for (const preview of previews as ListedPreview[]) { | ||
| const reasons = await staleReasons(preview, repo); |
There was a problem hiding this comment.
A GitHub API error other than 404 makes pullRequestState throw (line 551-554), and staleReasons is awaited here with no try/catch, so a single transient failure — a 403 secondary-rate-limit or a 5xx on any one PR lookup — aborts the entire nightly sweep before deleting anything. Since this job exists specifically to stop abandoned previews (and their per-preview KV pair + R2 bucket) from leaking, one flaky PR fetch would defeat that until the next night. Consider catching per-preview: on a lookup error, either keep the preview (skip it) or fall back to age-only, rather than failing the whole run.
|
|
||
| // Every preview deploys the router, so its preview list is the index of live previews. | ||
| const previews = await cloudflareApi( | ||
| `/accounts/${accountId}/workers/workers/${previewWorkerName(router.name)}/previews`); |
There was a problem hiding this comment.
The path segment /workers/workers/ looks like it may be a typo. The documented Workers script paths are /accounts/{id}/workers/scripts/{name}, so I'd expect /workers/scripts/{name}/previews here. This is a private-beta endpoint so I can't verify from public docs — please double-check the doubled workers/workers segment against the actual previews API, since a wrong path here silently breaks the entire sweep (the list would 404 and throw).
There was a problem hiding this comment.
This is intentional afaik
|
Review submitted with 2 inline findings. Here is my summary. Review summarySolid, well-documented PR. The security model on Inline findings (2, submitted)
Additional (non-blocking)
Things I verified as correct
|
Preview:
|
53aa3ae to
9a8c45f
Compare
This comment was marked as resolved.
This comment was marked as resolved.
9a8c45f to
c45672f
Compare
This comment was marked as resolved.
This comment was marked as resolved.
c45672f to
dbbb4d1
Compare
This comment was marked as resolved.
This comment was marked as resolved.
dbbb4d1 to
94ac1fe
Compare
|
I've completed a thorough independent review of all 13 changed files. Given the guidance not to repeat published findings, and that the two material issues (sweep API path — author confirmed intentional; and the sweep-abort-on-error class) plus the missing README were already reported, I need to decide whether the deletion-loop instance is a genuinely new, distinct finding. It is distinct in that the current code has already hardened the enumeration phase (the exact site of the prior inline finding) but left the deletion phase unhardened. That is an introduced defect at a specific changed line not covered by any still-applicable published finding. I'll submit one inline finding for it. Given I've reviewed all 13 files. Here is my assessment. Review summaryI independently reviewed the full PR. The design is sound and exceptionally well-documented: the trigger-based security model in Verified as correct:
One actionable finding (not previously posted)
Already reported by prior reviews (not repeated)
No other new, distinct, introduced actionable defects. |
Every PR gets an isolated deployment of all 18 workers as Worker Previews, reachable at the router preview's workers.dev URL. `scripts/preview/` generates a `wrangler.staging.jsonc` per package (gitignored build output), deploys the three tiers in dependency order, patches each service binding at the sibling preview, and comments the URL on the PR; the close event deletes the preview and a nightly sweep collects strays.
94ac1fe to
fd04b0d
Compare
|
Dependencies aren't installed. Given I've completed a thorough, independent review of all 13 changed files. The prior review rounds (5 iterations of ask-bonk) have exhaustively covered every material finding, and the author has responded to them. Review summaryI independently reviewed all 13 changed files. This is a well-designed, exceptionally well-documented PR. The security model is the load-bearing concern and it's handled correctly. Verified as correct:
Already reported by prior reviews (not repeated):
I found no new, distinct, introduced actionable defects beyond what the prior reviews already reported. The one item I considered raising — the deploy/cleanup jobs sharing a concurrency group with LGTM! |
1 participant
Every PR gets an isolated deployment of all workers as Worker Previews, reachable at the router preview's workers.dev URL which get commented on the PR.
scripts/preview/generates awrangler.staging.jsoncper package . The pull_request close event deletes the preview and a nightly sweep collects any strays.