Restrict publish job to the npm env#1972
Conversation
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1972 +/- ##
=======================================
Coverage 83.85% 83.85%
=======================================
Files 56 56
Lines 2465 2465
Branches 743 748 +5
=======================================
Hits 2067 2067
Misses 392 392
Partials 6 6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| # GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| publish: | ||
| name: Publish | ||
| if: needs.version.outputs.hasChangesets == 'false' |
There was a problem hiding this comment.
This is a little bit tricky. The previous job has 2 purposes:
- mode selection (version vs publish)
- eagerly executing the version mode
I think a cleaner design would be to introduce changesets/action/select-mode subaction - but that has to be implemented separately.
| - name: Create Release Pull Request or Publish to npm | ||
| - name: Publish to npm | ||
| # https://github.com/changesets/action | ||
| uses: changesets/action@6a0a831ff30acef54f2c6aa1cbbc1096b066edaf # v1 |
There was a problem hiding this comment.
why use the changesets action here it's effectively doing nothing, just do yarn release + probably pushing tags?
There was a problem hiding this comment.
Primarily for dogfooding purposes. It also ends up being responsible for:
- proper monorepo support
- tagging
- github releases
At the very least, the last thing can't be done inline as easily here.
There was a problem hiding this comment.
i think this is what we're going to want to do in the long run, let the PMs do the publishing the way they need to, then they can also handle their own special cases like workspaces, catalogs, etc.
as for right now, i would want to test running yarn publish or pnpm -r publish to see what it looks like before using it here
There was a problem hiding this comment.
Primarily for dogfooding purposes. It also ends up being responsible for:
- proper monorepo support
- tagging
- github releases
right, it might be good to move that to the cli or something but makes sense.
as for right now, i would want to test running yarn publish or pnpm -r publish to see what it looks like before using it here
To be clear I wasn't talking about using yarn/pnpm publish, I still meant using changeset publish via the release package.json script we have, not yarn publish, I was just talking about the use of the action here.
beeequeue
left a comment
There was a problem hiding this comment.
needs to be rebased to use pnpm and node --run
| - name: Create Release Pull Request or Publish to npm | ||
| - name: Publish to npm | ||
| # https://github.com/changesets/action | ||
| uses: changesets/action@6a0a831ff30acef54f2c6aa1cbbc1096b066edaf # v1 |
There was a problem hiding this comment.
i think this is what we're going to want to do in the long run, let the PMs do the publishing the way they need to, then they can also handle their own special cases like workspaces, catalogs, etc.
as for right now, i would want to test running yarn publish or pnpm -r publish to see what it looks like before using it here
|
@beeequeue this targets the |
|
oh, my bad |
No description provided.