Breaking: separate releases into "generate" and "publish" phase #27
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This updates `eslint-release` to have separate commands for generating a release locally, and publishing info about the release to various locations (npm, git, GitHub releases). In addition to making it easier to deal with failures (since we won't end up in a half-published state), this will also make it possible to provide a 2FA code for publishing that will still be valid when it's actually time to publish. To make future changes easier, this also removes some functionality that is no longer used (e.g. the distinction between CI and non-CI releases, and the ability to publish the changelog to GitHub changelog separately from the rest of the release) Migration for existing projects: * Projects that run the `eslint-release` command should run `eslint-generate-release` followed by `eslint-publish-release`. * Projects that run the `eslint-prerelease <releaseId>` command should run `eslint-generate-prerelease <releaseId>` followed by `eslint-publish-release`. * Projects that use `ReleaseOps.release(releaseInfo)` should run `ReleaseOps.generateRelease(releaseInfo)` followed by `ReleaseOps.publishRelease()`. When publishing, an `NPM_OTP` environment variable can optionally be used to authenticate the publish.
platinumazure
approved these changes
Oct 10, 2018
lib/release-ops.js
Outdated
| // Release needs a .npmrc file to work properly - token is read from environment | ||
| console.log("Writing .npmrc file"); | ||
| fs.writeFileSync(".npmrc", "//registry.npmjs.org/:_authToken=${NPM_TOKEN}"); | ||
| fs.writeFileSync(".eslint-release-info.json", JSON.stringify(releaseInfo)); |
There was a problem hiding this comment.
As a separate item, should we add .eslint-release-info.json to all ESLint organization repositories' .gitignore file?
There was a problem hiding this comment.
Sounds good to me. I'll add that to the "migration guide" at the top of this PR.
The npm publish is generally more likely to fail than the git push (e.g. as a result of making a typo in a OTP). This updates the script to try publishing to npm first, to avoid creating an inconsistent state if the npm publish fails.
This should make it slightly easier to figure out what's going on if any issues need to be debugged.
|
FYI, I pushed a couple minor changes that should help with debugging if something goes wrong. Feel free to review again if you'd like, otherwise I'll plan to merge this a bit later today. |
platinumazure
approved these changes
Oct 10, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This updates
eslint-releaseto have separate commands for generating a release locally, and publishing info about the release to various locations (npm, git, GitHub releases). In addition to making it easier to deal with failures (since we won't end up in a half-published state), this will also make it possible to provide a 2FA code for publishing that will still be valid when it's actually time to publish.To make future changes easier, this also removes some functionality that is no longer used (e.g. the distinction between CI and non-CI releases, and the ability to publish the changelog to GitHub changelog separately from the rest of the release)
Migration for existing projects:
eslint-releasecommand should runeslint-generate-releasefollowed byeslint-publish-release.eslint-prerelease <releaseId>command should runeslint-generate-prerelease <releaseId>followed byeslint-publish-release.ReleaseOps.release(releaseInfo)should runReleaseOps.generateRelease(releaseInfo)followed byReleaseOps.publishRelease()..eslint-release-info.jsonto.gitignore.When publishing, an
NPM_OTPenvironment variable can optionally be used to authenticate the publish.Refs: eslint/eslint#10631