Closed dbrugger closed 3 years ago
Publishing/modifying npm packages is restricted to owners. There is only one level of access.
https://docs.npmjs.com/cli/owner
A list of owners for carbon-components-react, for instance, is as follows. It is of note that they have a carbon-bot email address which I suspect is for automated publishing. Confirmation will be sort from @joshblack
$npm owner ls carbon-components-react abbeyhrt Abagail.Hart@ibm.com adavila adavila91@gmail.com carbon-bot carbondesignsystem@gmail.com dakahn da.anguiano@ibm.com emyarod afw5059@gmail.com jnm2377 josefinanoemi4@gmail.com joshblack joshblack@us.ibm.com tjegan tj.egan@icloud.com vpicone vp@vincepic.one
Without an automated build (as is the case for @carbon/vue) 'lerna publish' can be used to manage the publication of multiple packages from a repo.
Let me know if we can help out with this, if publishing from CI we can provide an NPM_TOKEN for the carbon-bot.
Similarly, we can create a group of users under the @carbon
scope and give them access to the relevant packages.
Lerna is a great tool for publishing, especially with the conventional commit flag. Let me know if you want to chat about it at all!
For the first release, I'd be happy with enough configuration that enables us to automate the publishing of a package and tag based on conventional commits.
@SimonFinney very nice, lerna version
has a --conventional-commits
option for this: https://github.com/lerna/lerna/tree/master/commands/version#--conventional-commits
Similarly, you can use --conventional-prerelease
and --conventional-graduate
for a prerelease workflow.
It should help generate relevant tags and release changelogs (and CHANGELOG.md files) too!
There's also the option to use lerna publish
, which includes a call to lerna version
from the command line to publish to npm.
@carbon-design-system/ibm-cloud-paks See https://github.com/carbon-design-system/carbon/blob/master/docs/guides/endgame.md for how we might want to model our release process
@SimonFinney if it helps out, we simplified a bit from that end game process to basically the following:
One flow that we used before (that unfortunately is busted because of a lerna challenge we have) is a nightly release flow (published under the nightly
tag) that is a nice complement to the time-based cycle for teams that want to stay up-to-date (or if we want teams to help with experimented with stuff)
The last part of this process is that our "release team" cycles every month. The release team has two members, a lead and a side-kick. The lead owns the release along with training the side-kick. They are also on-deck for handling any release-related problems reported on GH or Slack, alongside determining release scope (what should / should not go into a release)
Thanks @joshblack ! That certainly helps simplify it - So far, my current thinking is:
For the short-term, I was thinking we could just publish on every merge to master
and figure out any additional channels, configuration, and steps when required.
Acceptance criteria to be defined in GitHub by owner in collaboration with group