Use legacy changelog action for non-stable channels#10940
Conversation
PR #10832 gated the generate_changelogs job to stable-only to save agent tokens on dev/preview/beta cuts. That gating broke the dev in-app changelog: the dev client fetches changelog.json from GCS first (app/src/autoupdate/changelog.rs:84) and falls back to channel_versions.json's changelogs.dev.latest on 404. Skipping the upload for dev releases caused the client to fall back to a stale 2021 test fixture in channel_versions.json containing "[TEST]" oz_updates entries, which then surfaced in the in-app "What's new in Oz" section for the most recent dev release. Reverting the gate restores the prior behavior where every release (stable/preview/dev) gets a fresh changelog.json uploaded to GCS, preventing the fallback path from ever being hit for dev. The stale channel_versions.json fixture should also be cleaned up separately in the warpdotdev/channel-versions repo.
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
There was a problem hiding this comment.
Overview
This restores the generate_changelogs job to run for every published release channel instead of only stable, so each channel can upload a fresh changelog.json.
Concerns
- No blocking correctness or security concerns found in the changed workflow condition.
Verdict
Found: 0 critical, 0 important, 0 suggestions
Approve
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
danielpeng2
left a comment
There was a problem hiding this comment.
Can we use the old (non-agent) changelog generation step for non-stable runs, instead of running the new agent flow?
Splits generate_changelogs to fan out by channel: - Stable: runs the Oz changelog-draft agent (new flow from #10832) - Non-stable (dev/preview/beta): restores the legacy warpdotdev/generate-changelog action A small bridge step picks the right source and re-emits it as outputs.changelog, so the downstream Slack/GCS steps are unchanged. This fixes the dev in-app changelog regression introduced by #10832 (dev clients fall back to a stale channel_versions.json fixture when the GCS changelog.json upload is skipped — see app/src/autoupdate/changelog.rs:84) without spending Oz agent tokens on daily dev cuts and preview RCs. The Oz flow stays in the loop on stable, where the higher-quality output matters most.
|
Sure, I updated here as suggested. Non-stable channels use the old changelog action |
74fac75 to
ba7257e
Compare
Summary
Fixes the dev in-app changelog regression from #10832 without re-running the Oz agent on every non-stable cut.
warpdotdev/generate-changelogaction, so a freshchangelog.jsonis uploaded to GCS for every cut.steps.generate_changelog.outputs.changelog, so the downstream Slack post + GCS upload steps work unchanged.Background
#10832 gated
generate_changelogsto stable-only to save agent tokens. That broke the dev in-app changelog: the dev client fetcheschangelog.jsonfrom GCS first (app/src/autoupdate/changelog.rs:84—should_fetch_changelog_jsonistrueonly forChannel::Dev) and falls back tochannel_versions.json'schangelogs.dev.lateston 404. Skipping the upload for dev releases caused the client to surface a 2021-era[TEST]fixture fromchannel_versions.jsonin the in-app "What's new in Oz" section.Preview/stable read straight from
channel_versions.json(no GCS), so they were never exposed to the bug. The follow-up cleanup of the stalechangelogs.dev.latestfixture inwarpdotdev/channel-versionsis in flight separately and is good hygiene regardless.Why hybrid instead of "new flow everywhere"
workflow_dispatchchangelog_draft.ymlfor ad-hoc runsTest plan
warp-releases/dev/<release_tag>/changelog.jsonis uploaded[TEST]fixtures)🤖 Generated with Claude Code