Filter nightly builds by finished state to avoid picking up concurren…#18739
Open
SanabriaRusso wants to merge 2 commits intodkijania/nightly-promoter-pipelinefrom
Open
Filter nightly builds by finished state to avoid picking up concurren…#18739SanabriaRusso wants to merge 2 commits intodkijania/nightly-promoter-pipelinefrom
SanabriaRusso wants to merge 2 commits intodkijania/nightly-promoter-pipelinefrom
Conversation
Replace the tear-down-based AutoPromoteNightly job with a standalone
pipeline that runs independently after nightly builds complete. The
nightly-promoter Go binary queries the Buildkite API for the latest
build, verifies all Debian/Docker packaging jobs passed, computes
source/target versions from git, and calls manager.sh to publish
both Debian packages and Docker images.
Architecture:
- Single Buildkite step with three commands sharing the same agent
- Go binary built inside Docker (minaToolchain has Go)
- Debian publish inside Docker (needs GPG, deb-s3, AWS creds)
- Docker publish on host (needs Docker daemon)
- API auth via BUILDKITE_AGENT_WRITE_TOKEN (same as hardfork runner)
New files:
- buildkite/src/Entrypoints/PromoteNightly.dhall
- buildkite/scripts/entrypoints/run-nightly-promoter.sh
- buildkite/scripts/pipeline/cmd/nightly-promoter/main.go
- buildkite/scripts/pipeline/cmd/hardfork-runner/main.go
- buildkite/scripts/pipeline/internal/{bk,gcs}/
Removed:
- buildkite/src/Jobs/Promote/AutoPromoteNightly.dhall
- buildkite/scripts/pipeline/run-hardfork-pipeline.go
Also refactors Publish.dhall for readability (no functional changes)
and restructures Go pipeline tools into multi-binary layout.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…t runs When the nightly promoter runs while a new nightly build is in progress, the unfiltered ListBuilds call picks up the running build and fails with a confusing 'jobs still running' error. Filter for passed/failed builds so we always promote the latest completed nightly. We include 'failed' because the existing checkPackageJobs logic already inspects individual Debian/Docker job states — a build marked failed may still have all packaging jobs passed.
Member
Author
|
!ci-build-me |
4 tasks
dkijania
force-pushed
the
dkijania/nightly-promoter-pipeline
branch
4 times, most recently
from
197c7eb to
a62bf35
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Filter nightly builds by finished state to avoid picking up concurrent runs
When the nightly promoter runs while a new nightly build is in progress, the unfiltered
ListBuildscall picks up the running build and fails with a confusing "jobs still running" error. Filter for passed/failed builds so we always promote the latest completed nightly. We include "failed" because the existingcheckPackageJobslogic already inspects individual Debian/Docker job states — a build marked failed may still have all packaging jobs passed.