Repository navigation
CLDSRVCLT-21: Release prereleases from the BNaaS D1 epic - #31
anurag4DSB wants to merge 2 commits into
Conversation
The release workflow ran only from development/* and hotfix/* branches, and it always published under the npm dist-tag latest. An epic branch needs its own tags without moving latest. An epic/* branch can now release, but only a prerelease version (one with a "-" part, such as 1.0.14-bnaas.1). Every prerelease version goes to npm and GitHub Packages under the dist-tag prerelease, and its GitHub release is marked as a prerelease. A GA version from development/* or hotfix/* releases as before, under latest.
Set the version on the BNaaS D1 epic to its first epic tag. The release workflow then publishes 1.0.14-bnaas.1 from the epic branch under the dist-tag prerelease, and latest stays on 1.0.13. Epic branch: epic/S3C-10971-bnaas-d1 Cut from: development/1.0 at fb6dd25 on 2026-10-14 Last release on that line: 1.0.13 Changes since that release: 1.0.13...fb6dd25
This is not on official branch, its on epic branch. We will revert the change once we are merging epic branch to development, noted |
The point of this limit is to prevent making (official!) releases from non official branches. So it should not even be done on these branches! |
we will not be releasing official tags, the tags will be prefixed with a.b.c-bnaas.1, like this: scality/Arsenal#2737 |
|
fat fingered on close |
|
closing this PR as we found an alternate |
3 participants
Intent: why does this change exist?
The BNaaS D1 epic needs its own cloudserverclient tag, but the release workflow refuses any branch other than
development/*andhotfix/*, and it always moveslatest. This PR does task 3, row 3.4 in the Tickets tab of the BNaaS D1 tech spec.System impact: what's affected, including downstream?
Only the release workflow and the version on the epic branch. A manual release runs the workflow file of its own branch, so this works from the epic without a change to
development/1.0, and it reaches development with the final merge of the epic. CloudServer does not use the typed client yet, so nothing waits on this tag.Preserved behavior: what explicitly stays the same?
A GA version from
development/*orhotfix/*releases as before: dist-taglateston npm and GitHub Packages, and a normal GitHub release. No past release was a prerelease, so no existing flow changes.Intended change: what's different after this PR?
An
epic/*branch can release, but only a prerelease version (one with a-part), and any other version fails early. A prerelease goes under the dist-tagprerelease, and its GitHub release is marked as a prerelease, solateststays on 1.0.13. The second commit bumps the epic to1.0.14-bnaas.1.Verification: how do we know this worked, or how would we know if it didn't?
actionlint with shellcheck reports nothing new. I ran the new step locally for development, hotfix and epic refs with GA, prerelease and build-metadata versions, and
npm publish --dry-run --tag prereleasepasses with npm 10 and 11. After the release,npm view @scality/cloudserverclient dist-tagsmust showlatest: 1.0.13andprerelease: 1.0.14-bnaas.1.