Improvement: retryable release publishing#634
Draft
krzysztof-causalens wants to merge 4 commits into
Draft
Conversation
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.
Motivation and Context
The release workflow currently publishes packages before it pushes the version bump commit and moves the release tag. If publishing partially succeeds and the later git step fails, retries can hit already-published PyPI or npm artifacts and fail again.
This PR makes the tag-triggered release path safer to retry while keeping the normal "push a version tag" workflow.
Implementation Description
The release workflow is split into a prepare phase and a publish phase. The prepare phase finds the exact remote branch head that the release tag points to, creates the version bump commit, verifies the branch has not moved, pushes the commit, and retargets the tag before any registry publish starts.
The publish phase checks out that prepared release commit and publishes artifacts with idempotent behavior: PyPI uses
poetry publish --skip-existing, npm useslerna publish from-packagewithout--force-publish, and docs upload skips existing versioned artifacts. A completed GitHub release is treated as the terminal marker, so reruns do not duplicate publishing or Slack once the release already exists.No package changelog entry is included because this only changes release infrastructure.
Any new dependencies Introduced
None.
How Has This Been Tested?
.github/workflows/release.ymlas YAML.Prepare release commitbash block withbash -n.git diff --check.make -n publish-python publish-npm.poetry checkfor the root project,packages/dara-core,packages/dara-components, andpackages/create-dara-app.poetry run python -m py_compile tooling/scripts/docs-upload.py.PR Checklist:
Screenshots (if appropriate):
N/A