Repository navigation
ARSN-660: Release from the epic with no GitHub release - #2740
Closed
anurag4DSB wants to merge 1 commit into
Closed
anurag4DSB wants to merge 1 commit into
anurag4DSB wants to merge 1 commit into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## epic/S3C-10971-bnaas-d1 #2740 +/- ##
========================================================
Coverage 75.38% 75.38%
========================================================
Files 226 226
Lines 18633 18633
Branches 3895 3895
========================================================
Hits 14046 14046
Misses 4582 4582
Partials 5 5 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
The official release workflow does not run from an epic branch, so the BNaaS D1 epic carries its own copy of it. The copy also accepts epic/* branches, and it creates only the git tag, with the job token, where the original creates a GitHub release. Everything else stays as in development: the package goes to npm and GitHub Packages under the dist-tag latest-X.Y.Z-bnaas, and the existing checks still refuse a version whose tag or release already exists. The copy exists only on the epic, and the final merge drops it.
anurag4DSB
force-pushed
the
improvement/ARSN-660-epic-release-workflow
branch
from
October 22, 2026 16:26
152ac3f to
672094e
Compare
anurag4DSB
marked this pull request as ready for review
October 22, 2026 16:29
Contributor
Author
|
Closing: D1 will not release from the epic branches. Arsenal and cloudserverclient changes go through the development branches and ship in normal releases, and Federation pins the CI images of the epics by commit sha. |
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.
Intent: why does this change exist?
The official release workflow does not run from an epic branch (cloudserverclient#31), so the D1 epic carries its own copy of it, and we release by running that copy from the epic. The copy differs from development only where the original creates a GitHub release. It is row 3.1 of the Tickets tab.
System impact: what's affected, including downstream?
Only
.github/workflows/release.yamlon the Arsenal epic. A run publishes@scality/arsenalto npm and GitHub Packages underlatest-X.Y.Z-bnaas, so CloudServer, backbeat and Vault can pin the exact version.Preserved behavior: what explicitly stays the same?
Every other job and step stays as in development, including the checks that refuse a version whose tag or release already exists. Development keeps its own file, and the final merge drops this copy.
Intended change: what's different after this PR?
The branch check also accepts
epic/*, and the last step creates the git tag with the job token (gh api .../git/refs) instead of creating a GitHub release. The hand-pushed8.6.1-bnaas.1tag was deleted, so the first run creates it again on the same commit and publishes8.6.1-bnaas.1.Verification: how do we know this worked, or how would we know if it didn't?
actionlint reports nothing new. After the merge, one run from the epic must make
npm view @scality/arsenal@8.6.1-bnaas.1answer and create the tag8.6.1-bnaas.1, with no GitHub release.