fix(ci): redeploy the CDN after the release and gate on it catching up - #43
Conversation
The site autodeploy fires on the push that starts the release, but build-cdn.mjs reads the version from npm dist-tags, which only moves when the publish finishes. The first build baked in the previous version and nothing rebuilt it, so 0.13.0 stayed invisible to every installed client while CI reported success. Add a redeploy-cdn job that fires the Dokploy webhook after publish-native-assets, and turn the consistency check from a warning into a poll that fails when the CDN never catches up.
The started line rendered dot and wording in periwinkle and the completed line rendered both in green, so an ambient background task drew as much attention as the work the user asked for. Keep the wording dim on every phase and colour the bullet alone: dim while running, green on completion, red on failure.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 46 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe release workflow redeploys the CDN after publishing and polls until the CDN matches npm. CDN-ahead and timeout states fail verification. Background task status wording is dimmed while status bullets retain phase-specific colors. ChangesCDN release consistency
Background task status styling
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Release
participant Dokploy
participant CDN
participant Verification
Release->>Dokploy: trigger CDN redeployment
Dokploy-->>Release: return webhook result
Release->>Verification: start CDN consistency check
Verification->>CDN: poll release manifest
CDN-->>Verification: return CDN version
Verification-->>Release: report match, ahead, or timeout
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Comment |
commit: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (1)
apps/pythinker-code/test/tui/components/messages/background-agent-status.test.ts (1)
67-68: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRemove the conditional fallbacks from the render lookup.
Oxlint reports
vitest(no-conditional-in-test)on Lines 67-68. Read the rendered values directly and assert that they are defined before checking their contents. This keeps a missing render line explicit.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/pythinker-code/test/tui/components/messages/background-agent-status.test.ts` around lines 67 - 68, Update the render lookups in the test around started and completed to read the indexed rendered lines directly without conditional fallback operators. Assert both retrieved lines are defined before checking their contents, preserving explicit failure when the expected render line is missing.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 238-250: The webhook handling block must validate WEBHOOK starts
with https:// before invoking curl. Add a guard after the empty-value check that
skips the deployment and exits successfully for any non-HTTPS URL, leaving curl
unreachable in that case.
- Around line 250-254: Update the curl invocation in the CDN redeploy webhook
step to include the --fail option, ensuring HTTP error responses produce a
nonzero status and trigger the existing retry and warning behavior.
In
`@apps/pythinker-code/test/tui/components/messages/background-agent-status.test.ts`:
- Line 59: Update the completed-detail fixture in the background-agent status
test to replace the non-ASCII middle dot with an ASCII separator, keeping
Unicode values out of this non-Unicode test.
In `@scripts/release/cdn-consistency.mjs`:
- Around line 68-78: Update the polling flow around readCdnVersion and the
classification === 'match' return to check now() >= deadline after the fetch
completes, rejecting or continuing according to the existing deadline behavior
before accepting a match. Add a fake-clock test covering a fetch that completes
after the deadline and verifies the release gate does not pass.
- Around line 19-24: Update compareRelease in
scripts/release/cdn-consistency.mjs to avoid Number conversion: compare each
numeric identifier by digit-string length first, then lexicographically when
lengths match, preserving release ordering without precision loss. Add a
regression assertion in
apps/pythinker-code/test/scripts/release/cdn-consistency.test.ts lines 44-51
covering adjacent identifiers beyond safe-integer precision.
---
Nitpick comments:
In
`@apps/pythinker-code/test/tui/components/messages/background-agent-status.test.ts`:
- Around line 67-68: Update the render lookups in the test around started and
completed to read the indexed rendered lines directly without conditional
fallback operators. Assert both retrieved lines are defined before checking
their contents, preserving explicit failure when the expected render line is
missing.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 2e2a4f02-7875-40e7-aadb-78cb4b3d6561
📒 Files selected for processing (7)
.changeset/dim-background-task-status-wording.md.github/workflows/release.ymlapps/pythinker-code/src/tui/components/messages/background-agent-status.tsapps/pythinker-code/test/scripts/release/cdn-consistency.test.tsapps/pythinker-code/test/tui/components/messages/background-agent-status.test.tsscripts/release/cdn-consistency.mjsscripts/release/verify-release-consistency.mjs
Reject a non-https webhook URL before curl sees it, and add --fail so an HTTP error status reaches the retries and the warning instead of exiting 0. Compare release identifiers with BigInt so two versions past 2^53 cannot round to the same float and read as a match. Drop the conditional fallbacks from the status colour test.
|
@coderabbitai All 5 inline findings triaged and every thread resolved, through Fixed (3)
Dismissed with rationale on-thread (2) — the ASCII-fixture nit (the middle dot is the separator the component itself emits at Nitpick — Docstring coverage — documented the one genuinely undocumented function in the new module ( Each behaviour change above is covered by a test that was mutation-verified to fail when the fix is reverted. |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/release.yml (1)
279-281: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winRun
verify-cdn-releasewhenredeploy-cdnis skipped.Add
always()and requireneeds.release.result == 'success'in the job condition. Otherwise, a skippedredeploy-cdnskips the CDN consistency gate.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 279 - 281, Update the verify-cdn-release job condition to use always() while requiring needs.release.result == 'success', so it still runs when redeploy-cdn is skipped. Preserve the existing needs.release and needs.redeploy-cdn dependencies.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.github/workflows/release.yml:
- Around line 279-281: Update the verify-cdn-release job condition to use
always() while requiring needs.release.result == 'success', so it still runs
when redeploy-cdn is skipped. Preserve the existing needs.release and
needs.redeploy-cdn dependencies.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 8cff521c-cf36-4743-a05c-7b6c7f20eb8f
📒 Files selected for processing (4)
.github/workflows/release.ymlapps/pythinker-code/test/scripts/release/cdn-consistency.test.tsapps/pythinker-code/test/tui/components/messages/background-agent-status.test.tsscripts/release/cdn-consistency.mjs
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/pythinker-code/test/tui/components/messages/background-agent-status.test.ts
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
git show --no-ext-diff --stat --oneline dc94f1da29c9172675eae85e821db6a327d0fd8b
git show --no-ext-diff --format=fuller --find-renames \
dc94f1da29c9172675eae85e821db6a327d0fd8b -- \
.github/workflows/release.yml \
scripts/release/cdn-consistency.mjs \
scripts/release/verify-release-consistency.mjs \
apps/pythinker-code/test/scripts/release/cdn-consistency.test.ts \
apps/pythinker-code/test/tui/components/messages/background-agent-status.test.ts \
apps/pythinker-code/src/tui/components/messages/background-agent-status.ts
printf '\n--- Relevant declarations and assertions ---\n'
rg -n -C 4 \
'compareRelease|BigInt|readCdnVersion|https:|--fail|DOKPLOY|WEBHOOK|9007199254740992|9007199254740993|rendered.*join|join\(.*render' \
.github/workflows/release.yml \
scripts/release/cdn-consistency.mjs \
apps/pythinker-code/test/scripts/release/cdn-consistency.test.ts \
apps/pythinker-code/test/tui/components/messages/background-agent-status.test.tsLength of output: 12971
The workflow rejects non-HTTPS webhook URLs before
The ✏️ Learnings added
You are interacting with an AI system. |
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @pythoughts/pythinker-code@0.13.1 ### Patch Changes - [#43](#43) [`0ea74d4`](0ea74d4) - Dim the wording on background task status lines so only the status dot is coloured. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
1 participant
Related Issue
No issue — the problem is described below.
Problem
The CDN never learns about a new release, so no installed client sees it.
0.13.0published to npm at13:52:23Zon 2026-08-08. An hour laterhttps://code.pythinker.com/pythinker-code/latest.jsonstill advertised0.12.0, and every client's update check loggedreason: "not-newer". CI was green throughout.The cause is an ordering race:
13:43:42Z— theci: release packagescommit is pushed to main, which is what starts the release.13:44:06Z— Dokploy autodeploy, triggered by that same push, builds the site.apps/site/scripts/build-cdn.mjsresolves the advertised version fromnpm view … dist-tags, which still reads0.12.0.13:52:23Z— the publish finishes and the dist-tag moves.verify-release-consistency.mjsalready noticed this and only loggedCDN is behind npm … it catches up on the next push to main. It failed solely when the CDN was ahead, which is why the check stayed green through the whole incident.What changed
A redeploy is fired after the publish. A new
redeploy-cdnjob POSTs the existingDOKPLOY_CDN_DEPLOY_WEBHOOKsecret. It is ordered afterpublish-native-assets, becauselatest.jsononly gets its per-platformplatformsblock once the native zips exist on the release.That job needs
always():publish-native-assetsskips on an npm-only release, and a job whoseneedsincludes a skipped job is skipped too.always()then removes the implicit success requirement, so the upstream results are asserted explicitly — it runs on a normal release and on an npm-only release, and not when the release failed or was cancelled.The webhook step cannot fail the workflow. npm has already published by the time it runs, so dying on a flaky POST buys nothing — an earlier version of this job was deleted precisely because a
curlexit-28 timeout failed the 0.5.0 release. It retries, then degrades to a warning. The webhook also matches the branch from the request body, so it sendsContent-Type: application/jsonwith{"ref":"refs/heads/main"}; a bare POST answers301 Branch Not Matchand deploys nothing.The consistency check became a real gate.
verify-cdn-releasenow runs afterredeploy-cdnand polls until the manifest matches npm, failing when it never does. The previously warn-and-skip "CDN unreachable" branch folds into the same mechanism: a fetch error, a non-ok status and an unparseable manifest are all treated as lag and retried, since mid-deploy the origin is legitimately unreachable.aheadstill fails at once, because more waiting cannot fix a manifest naming a release npm does not have. The 10-minute budget sits under the job's 15-minute timeout so a stale CDN is reported rather than killed by the runner.The poll logic lives in a new
scripts/release/cdn-consistency.mjswith fetch, sleep and clock injected, so it is unit tested with no network and no real waiting.Unrelated to the above, in the same branch: background task status lines rendered dot and wording in periwinkle while running and both in green on completion, so an ambient background task drew as much attention as the work the user asked for. The wording is now dim on every phase and only the bullet carries status — dim while running, green on completion, red on failure.
Checklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.Summary by CodeRabbit
UI Improvements
Release Reliability
Tests