feat: Generic & CircleCI Trusted Publishing#1122
Conversation
|
@travi any way you could consider merging this so those of us using semantic release on circle can use trusted publishing? |
|
one of my hesitations with this approach is the generic handling. the npm docs still only list three supported providers. suggesting that a generic approach can work beyond that list goes beyond what i think the npm team has defined. i'm ok with adding circle to our supported list, but i think i would still want to handle it specifically rather than generically. i think the path to more generic support depends on what the npm team ends up doing with npm/cli#8525 because i want to avoid us being in the game of keeping up with each additional ci provider enabled by the npm team |
| | Variable | Description | | ||
| | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | `NPM_TOKEN` | Npm token created via [npm token create](https://docs.npmjs.com/getting-started/working_with_tokens#how-to-create-new-tokens) | | ||
| | `NPM_ID_TOKEN` | OIDC identity token for [trusted publishing](https://docs.npmjs.com/trusted-publishers). Must be configured in your CI job (see [GitLab](#trusted-publishing-for-gitlab-pipelines), [CircleCI](#trusted-publishing-for-circleci)). Takes priority over CI-specific token retrieval when set. | |
There was a problem hiding this comment.
Must be configured in your CI job
i think we need some adjustment here to clarify that this is only needed for specific ci providers. the current wording doesnt make it clear that this is not required in the context of github actions, for example
There was a problem hiding this comment.
What if you just added "This is not required when using trusted publishing in Github Actions." after the parenthetical and before the "takes priority..."?
There was a problem hiding this comment.
i'm good with @chammond-tz's suggestion or similar for this one. however, i'm still looking for the overall change to be focused specifically on circle ci and not generic. as mentioned in another comment, we are looking for the npm team to lead what the approach should be for more generic handling
I specifically did the 'generic' so the semantic-release team wouldn't need to chase every added CI provider and because that is the way npm works in practice, even if it's not documented that way. Frankly, its saddening that NPM is picking specific vendors to support over creating open standards in this case. |
dopry
force-pushed
the
feat/circleci-trusted-publishing
branch
from
e192430 to
c4d56cf
Compare
- add generic support for trusted publishing via NPM_ID_TOKEN to decouple semantic release from CI platforms. - document trusted publishing with CircleCI
dopry
force-pushed
the
feat/circleci-trusted-publishing
branch
from
c4d56cf to
0859db4
Compare
i understand the goal of simplifying here, but the OIDC handshake is limited to approved trusted providers, so it isnt fully generic. until npm would release support for generic providers, which i dont think is likely or even technically possible, i dont think we should advertise generic support here. as mentioned in #1122 (comment), we need something to happen on the npm side of the equation in order for us to be able to simplify here |
4 participants
fixes #1121