Repository navigation
nightly: end an already-published recovered build as a no-op - #20986
Conversation
… failure Run 38689026338 and its continuation 38689412336 took the same recovered build; the second recheck found it on the feed and failed the run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
When another run has already published the recovered build, the recheck now notices it, sets already_published, and every later publish-nightly step and republish-nightly-deltas skip. A build below any feed still fails. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bugbot needs on-demand usage enabledBugbot uses usage-based billing for this team and requires on-demand usage to be enabled. A team admin can enable on-demand usage in the Cursor dashboard. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Bead |
…covered build (#21144) * nightly: run publication tooling from the workflow commit, not the recovered build publish-nightly checks out the published build's commit. A recovered build can be days older than the workflow: run 38855116561 recovered 0664bd9, whose nightly_version.py predates --already-published-ok (#20986), so the recheck failed with unrecognized arguments. The same skew would break publish-release-assets.py --github-output and finalize-release.py (#21139). Check out scripts/ at github.sha into .publish-tooling and run the publication tooling from there: nightly_version, nightly_release_notes, nightly-next-guard, prune, publish-release-assets, finalize-release, upload-r2-object and update-release-tag. Scripts that read the build's own source tree stay on the publish ref. * nightly: pin every moved publication script to the tooling checkout in the test Review follow-up for #21144. * test: accept the publication tooling path for the release tag helper * test: allow the publication tooling checkout at github.sha in publish-nightly
nightly-next push run 38689026338 went red in
publish-nightlyalthough nothing was wrong. It and its continuation run 38689412336 both took recovered build 3865928435701. The continuation published it at 06:02Z, so at 06:56Z the push run's recheck printedbuild 3865928435701 is not above 3865928435701 in https://files-next.cmux.com/nightly-next/next/appcast-arm64.xmland exited 1.Now, when no feed is above the recovered build and some feed already offers that exact build, the recheck posts a notice ("build X is already published; nothing to do") and sets
already_published=true. Every laterpublish-nightlystep skips, and so doesrepublish-nightly-deltas, which gets a newalready_publishedjob output. A build below any feed still fails, as before.scripts/ci/nightly_version.py check-build --already-published-okallows an equal highest build and printsalready_published=true|falselast. Without the flag, behavior doesn't change.tag_statusempty (the marker step skips), soreport-nightly-failuredoesn't fire.close-nightly-failure-issuedoesn't fire either; the run that published the build owns the issue.publish-nightly-identity-legacyis untouched.Testing
python3 -m unittest tests.test_nightly_next_recoveryruns the real recheck step against local feed copies and evaluates the real jobifs.Also green:
python3 tests/test_nightly_version.py(9/9), and~/.local/bin/actionlint .github/workflows/nightly.yml. The other tests that read nightly.yml pass, excepttest_ci_change_areas.py,test_ci_select_package_tests.pyandtest_ci_self_hosted_guard.sh. Those fail on unrelated paths (Packages/Shared change areas, a tempcallsfile, runner labels in other workflows). I didn't run the workflow live.Changelog
none
🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need.Summary by cubic
Fixes the nightly publish recheck treating an already-published recovered build as a failure, which turned the push run red even though the build was published by a continuation run. The recheck now detects that case, ends as a no-op with success, and skips all later publish steps and delta republishing. A build below any feed still fails as before.
nightly_version.py check-buildgains--already-published-ok, which accepts an equal highest build and printsalready_published=true|false; behavior without the flag is unchanged.tag_statusempty so failure reporting and issue-closing steps do not fire.Written for commit 35b2398. Summary will update on new commits.