Repository navigation
ci(release): publish each release batch in dependency order - #93
Merged
Merged
Conversation
Each component release used to start its own run, and an integration's publish job waited about two minutes for its core package. When release #78 created 22 releases at once, core publication was still waiting for runners when those waits ran out, and 13 publish runs failed. The run for the release PR's merge commit now publishes every released package in release-please-config.json order, in one job per registry, so core packages go out first and no job holds a runner while it waits. Per-tag retries from main still work.
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
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.
Release #78 created 22 component releases, and 13 of their publish runs failed. Each release started its own run, and an integration's publish job gave its core package (
@telemetry-dev/otel,@telemetry-dev/sdk, ortelemetry-devon PyPI) about two minutes to appear on the registry. Core publication was still in progress when those waits ran out; the core Python publish job alone waited almost three minutes for a runner. All 13 succeeded on retry.The run for the release PR's merge commit now publishes every package that merge released, in
release-please-config.jsonorder, in one job per registry. Core packages go out before the integrations that depend on them, and no job holds a runner while it waits for another job to start. Therelease: publishedtrigger is removed, and per-tagrelease_tagretries frommainwork as before. Dependency waits are now about 10 minutes for npm and PyPI, and the Python dependency check runs just before each upload instead of in the build job.This reverses the old rule in
RELEASING.mdthat each release publishes only its own package. The cost is that one failing package stops the packages after it in the same registry job. Re-running the merge commit's run recovers, since it skips versions already published, andRELEASING.mdnow describes which re-run to use.Discovery selects a package when release-please reports it or when its computed tag points at the pushed commit. The second rule covers a re-run after release-please failed partway through creating releases: on the re-run it skips releases that already exist, so
paths_releasedalone would leave them unpublished. The release-please job has its own concurrency group withqueue: max, because the default queue cancels a waiting job when another push arrives, and that job now decides what the merge publishes. actionlint 1.7.12 does not knowqueueyet, so.github/actionlint.yamlignores that one error in this workflow.The release tests now also check that the config lists each package after its dependencies, since a wrong order would stall the whole batch.