Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: update publishing scripts #28118

Merged
merged 2 commits into from
Nov 17, 2020
Merged

chore: update publishing scripts #28118

merged 2 commits into from
Nov 17, 2020

Conversation

vladar
Copy link
Contributor

@vladar vladar commented Nov 17, 2020

Description

This PR brings all the publishing scripts required for the new release process with additional benefits.

Branch protection

  • publish-next and publish-preminor are only allowed in the master branch
  • publish-release and publish-rc are only allowed in the release/* branches

This should prevent accidental publishing from a wrong branch (i.e. stable release from master or next release from the release branch).

Deprecated yarn run publish

Now it outputs a hint to run yarn publish-next or yarn publish-release.

Why? Lerna suggests not to use publish script for lerna publish calls:

Run publish lifecycle in root
To avoid recursive calls, don't use this root lifecycle to run lerna publish

We also had to use --ignore-scripts for --canary publishing because of this. Now canaries should work with scripts too.

Moved pre-publish scripts to lifecycle hooks

  • scripts/check-publish-access to prepublishOnly (as we don't want to run it on pack)
  • scripts/clear-package-dir to prepack (we want to run it for both - pack and publish)

@gatsbot gatsbot bot added the status: triage needed Issue or pull request that need to be triaged and assigned to a reviewer label Nov 17, 2020
@vladar vladar added type: maintenance An issue or pull request describing a change that isn't a bug, feature or documentation change and removed status: triage needed Issue or pull request that need to be triaged and assigned to a reviewer labels Nov 17, 2020
@vladar vladar requested a review from wardpeet November 17, 2020 10:36
@ascorbic
Copy link
Contributor

ascorbic commented Nov 17, 2020

Would it be worth adding a "publish-canary" command, to avoid messing it up?

Edit: I realise we have one already, but the existing script doesn't seem to match our documented command

@vladar
Copy link
Contributor Author

vladar commented Nov 17, 2020

Well, canary usually requires specific --pre-dist-tag and --preid anyway. So we can't have a single command for every canary. Also, I've removed preDistTag option from lerna config, so now even the old command for canary should just work.

@ascorbic
Copy link
Contributor

Yeah, I meqant something like yarn publish-canary create-gatsby

@KyleAMathews
Copy link
Contributor

@vladar
Copy link
Contributor Author

vladar commented Nov 17, 2020

That would be handy but I still don't quite understand how to interpolate canary name into both - --preid and --pre-dist-tag.

So with our recommended command for canary:

yarn lerna publish --canary --ignore-scripts --exact  --preid <preid> --pre-dist-tag <dist_tag>

We need to replace both <preid> and <dist_tag> with a command argument (that's a recommendation in our docs to use the same value for those flags for canaries).

Looks like it requires a separate script or am I missing something? I can revisit this in a follow-up PR unless there is a quick way to do this in yarn scripts.

@pieh pieh self-assigned this Nov 17, 2020
@pieh
Copy link
Contributor

pieh commented Nov 17, 2020

Let's skip canary releases nicer CLI command conversation from this PR. This PR should fix the problem of canary release pushing to next tag (when using command we used historically, not the updated one), so this is already a fix in this area

Copy link
Contributor

@pieh pieh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks correct after streamlining changelogs ( lerna will generate changelogs since last release tag and NOT since last time it generated changelog, so we shouldn't mix --no-changelog and publishes with changelogs - it should be consistent )

Rest of things looks good here, but changelogs for sure will need some follow up work (and decisions)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bot: merge on green Gatsbot will merge these PRs automatically when all tests passes type: maintenance An issue or pull request describing a change that isn't a bug, feature or documentation change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants