Publish arsenal to GitHub Packages and npm on release - #2657
Conversation
Hello delthas,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
Request integration branchesWaiting for integration branch creation to be requested by the user. To request integration branches, please comment on this pull request with the following command: Alternatively, the |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## development/8.4 #2657 +/- ##
===================================================
+ Coverage 74.41% 74.42% +0.01%
===================================================
Files 229 229
Lines 18539 18539
Branches 3842 3842
===================================================
+ Hits 13795 13798 +3
+ Misses 4739 4736 -3
Partials 5 5 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
c06db2c to
2b07c4a
Compare
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
2b07c4a to
ba6a25d
Compare
ba6a25d to
7d72e9c
Compare
3946f2a to
24ffbc9
Compare
delthas
changed the title
6a85917 to
45f5079
Compare
45f5079 to
dece6b0
Compare
maeldonn
left a comment
maeldonn
left a comment
There was a problem hiding this comment.
LGTM but we need to get team alignment on this first
54cde5f to
d263011
Compare
|
(Unrelated kmip failure due to #2668 ; will rebase once merged) |
tcarmet
left a comment
tcarmet
left a comment
There was a problem hiding this comment.
Looking good! Happy to see this change. I have one request on it which I made it clear, otherwise LGTM.
Extend the manual release workflow (ARSN-604) to build and dual-publish @scality/arsenal (a public, Apache-2.0 library) to GitHub Packages and npmjs, split into jobs so the build is produced once and each publish can be retried independently of it and of the other: - build: after the branch/version/tag guards, install, build, pack the tarball, generate a signed build-provenance attestation for it (actions/attest-build-provenance), and upload it as the artifact. - publish-github: download the tarball and publish it to GitHub Packages with the built-in GITHUB_TOKEN. - publish-npm: publish the same tarball to npmjs via OIDC trusted publishing (id-token, no stored token) with --provenance. - release: create the GitHub release, linking to both packages. Both publish jobs use the committed package.json version (no auto-bump), check the registry with npm view first and skip if that version is already published (so a partial dual-publish can be re-run cleanly), and publish under a v<major.minor> dist-tag so an older release line never moves the latest tag. Building and packing once, then attesting and publishing the same tarball to both registries, yields a single GitHub attestation covering whatever lands in either registry, plus npm-native provenance on npmjs. package.json is renamed to @scality/arsenal, drops the private flag, and gains types, files and publishConfig.access: public. The scoped name is committed directly rather than stamped at publish time: git-dependency consumers resolve arsenal by their dependency key, not the package name, so committing @scality/arsenal keeps require('arsenal') working for the current git consumers (verified) while making the published package correctly scoped. Token permissions are scoped per job. The workflow tests stub the publish path so the guard coverage is unchanged. Issue: ARSN-605
Reformat the two workflow files to satisfy the prettier check before the runner change, so that change stays prettier-clean. Issue: ARSN-605
Drop the aging ubuntu-22.04 pin on the CI workflows. These jobs control their own toolchain (pinned actions, tools from the runner image), so pinning the runner OS buys little and just leaves us on an old image. Issue: ARSN-605
d263011 to
e81b831
Compare
Add a `release: [published]` trigger alongside workflow_dispatch so publishing a GitHub Release ships @scality/arsenal automatically, rather than relying on someone remembering to dispatch the workflow. The build and publish jobs are shared; the dispatch-only pieces are gated on the event: - the branch guard, the "release already exists" and "tag already exists" guards, and the Create Release job run only on workflow_dispatch (where the workflow itself creates the release); - on a release event the release already exists, so a step instead verifies the release tag matches the committed package.json version (npm publishes that version regardless of the tag). The workflow tests cover both the dispatch and release paths. Issue: ARSN-605
|
@maeldonn Rerequesting review (after François + Thomas ACK) |
Integration data createdI have created the integration data for the additional destination branches.
The following branches will NOT be impacted:
You can set option The following options are set: approve |
Request integration branchesWaiting for integration branch creation to be requested by the user. To request integration branches, please comment on this pull request with the following command: Alternatively, the |
|
/reset |
Reset completeI have successfully deleted this pull request's integration branches. |
Request integration branchesWaiting for integration branch creation to be requested by the user. To request integration branches, please comment on this pull request with the following command: Alternatively, the |
|
/approve |
In the queueThe changeset has received all authorizations and has been added to the The changeset will be merged in:
The following branches will NOT be impacted:
This pull request does not target the following hotfix branch(es) so they
There is no action required on your side. You will be notified here once IMPORTANT Please do not attempt to modify this pull request.
If you need this pull request to be removed from the queue, please contact a The following options are set: approve |
|
I have successfully merged the changeset of this pull request
The following branches have NOT changed:
Please check the status of the associated issue ARSN-605. Goodbye delthas. |
5 participants
Summary
Builds on the manual release workflow from ARSN-604 (#2656): on release, build and dual-publish
@scality/arsenalto GitHub Packages and npmjs. arsenal is a public, Apache-2.0 library, so per the DevEx TAD it goes to both registries. Non-breaking — existing git-dependency consumers (cloudserver, backbeat, vault2) are untouched; migrating them to the registry is a later, organic step.release.yamlis split into jobs so the build is produced once and each publish can be retried independently of it and of the other:yarn build,npm pack, generate a signed build-provenance attestation for the tarball (actions/attest-build-provenance), and upload the.tgzas the artifact.GITHUB_TOKEN.id-token: write, no stored token) with--provenance.Both publish jobs use the committed
package.jsonversion (no auto-bump), check the registry withnpm viewfirst and skip if that version is already published — so a partial dual-publish can be re-run cleanly — and publish under av<major.minor>dist-tag so an older release line never moveslatest. Building and packing once, then attesting and publishing the same tarball to both registries, gives a single GitHub attestation (gh attestation verify <tarball> --repo scality/Arsenal) covering whatever lands in either registry, plus npm-native provenance on npmjs.Name: committed, not stamped
package.jsonis renamed to@scality/arsenaldirectly — no publish-time name stamp /jq. Git-dependency consumers resolve arsenal by their dependency key, not the package'sname, so committing the scoped name keepsrequire('arsenal')working for cloudserver/backbeat/vault2 (verified end-to-end: real arsenal committed as@scality/arsenal, consumed under the unchanged barearsenalgit key, installs tonode_modules/arsenaland resolves both bare and deeparsenal/build/...imports).package.jsonalso dropsprivateand addstypes/files+publishConfig.access: public. The version stays committed / manually bumped — auto-stamping is deferred to a later step.The workflow tests under
tests/workflowsstub the publish path, so the guard coverage is unchanged.Prerequisite (npmjs trusted publishing)
The npm publish uses OIDC trusted publishing — no
NPM_TOKEN. Before the first npm release, a trusted publisher must be registered for@scality/arsenal: GitHub orgscality, repoArsenal, workflowrelease.yaml(the same setup Sylvain did for@scality/cloudserverclient). Since@scality/arsenalisn't on npm yet, bootstrap it one of two ways:@scalitypublish rights (yarn build && npm publish --access public) to create the package, then register the trusted publisher. That first version has no provenance (local publish); the workflow provenance-signs every release after it and skips the bootstrapped version via itsnpm viewcheck.@scalitynpm org allows creating packages via OIDC — then the first workflow run creates it, no manual step.GitHub Packages needs no bootstrap (built-in
GITHUB_TOKEN).Aligned with the DevEx initiative (S3C-9725); mirrors the dual-publish model of
hdclient/cloudserverclient.Issue: ARSN-605