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

feat(version): Create Github releases with --github-release #1864

Merged
merged 16 commits into from Feb 8, 2019
Merged

feat(version): Create Github releases with --github-release #1864

merged 16 commits into from Feb 8, 2019

Conversation

milesj
Copy link
Contributor

@milesj milesj commented Jan 10, 2019

Would solve #1513

Description

This is a proof of concept so I'm looking for feedback. Is this something we want in Lerna? Would it be better as a future type of plugin? etc.

A bulk of the work already exists through conventional-commits + changelog generation. I updated the changelog logic to also return the new entry to use in the body of the GH release. I then wrapped everything in a --github command line option for opt-in purposes.

Other notes:

  • The GitHub client is its own package that requires specific env vars to exist.
  • I went with --github instead of --release, since the latter is a bit confusing, especially when terms like version and publish are thrown around. Furthermore, using --github permits additional features in the future, like adding labels to PRs.
  • It would be nice to use lerna-changelog but the APIs aren't very compatible.

Motivation and Context

I've been looking into using Lerna for auto-releases as a replacement for semantic-release (since it doesn't handle monorepos). The biggest drawback is the lack of GitHub releases, which most of my team wants, and is a requirement before we can switch over.

How Has This Been Tested?

N/A. I'll add tests if this change is good to move forward.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@evocateur evocateur added the WIP label Jan 10, 2019
Copy link
Member

@evocateur evocateur left a comment

Choose a reason for hiding this comment

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

Looks great so far, let's keep going!

utils/github-client/package.json Outdated Show resolved Hide resolved
utils/github-client/github-client.js Outdated Show resolved Hide resolved
return {
logPath: changelogFileLoc,
newEntry,
};
Copy link
Member

Choose a reason for hiding this comment

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

This is brilliant!

commands/version/index.js Outdated Show resolved Hide resolved
commands/version/index.js Outdated Show resolved Hide resolved
commands/version/index.js Outdated Show resolved Hide resolved
@milesj
Copy link
Contributor Author

milesj commented Jan 11, 2019

@evocateur Awesome to move forward on this! Made some adjustments based on feedback. I'll add tests once the implementation is done.

Copy link
Member

@evocateur evocateur left a comment

Choose a reason for hiding this comment

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

So far so good!

commands/version/index.js Outdated Show resolved Hide resolved
}

if (GHE_API_URL) {
options.baseUrl = GHE_API_URL;
Copy link
Member

Choose a reason for hiding this comment

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

Much clearer, thanks!

commands/version/lib/git-repo-url.js Outdated Show resolved Hide resolved
commands/version/index.js Outdated Show resolved Hide resolved
@milesj
Copy link
Contributor Author

milesj commented Jan 16, 2019

@evocateur Made changes. I think this is good to start adding tests.

Copy link
Member

@evocateur evocateur left a comment

Choose a reason for hiding this comment

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

Yep, looks great so far!

@milesj
Copy link
Contributor Author

milesj commented Jan 24, 2019

@evocateur I'm trying to write tests for the command but can't seem to get access to the releaseNotes array to verify what's been created. Is that possible at all? Since it's abstracted away around the yargs command runner.

@evocateur
Copy link
Member

The showCommit assertion pattern in https://github.com/lerna/lerna/blob/master/commands/version/__tests__/version-conventional-commits.test.js isn't sufficient? You might need to modify the mock in commands/__mocks__/@lerna/conventional-commits.js to make it more nuanced.

@milesj
Copy link
Contributor Author

milesj commented Jan 25, 2019

I'll take a look at that, thanks.

@sidharthachatterjee
Copy link

This looks great! We're looking at generating GitHub releases with change logs at https://github.com/gatsbyjs/gatsby/ and eagerly waiting for this to get in!

Thank you for this @milesj

@evocateur
Copy link
Member

yep, just waiting for the remainder of the tests, then we're good to go

@milesj
Copy link
Contributor Author

milesj commented Jan 31, 2019

Yeah sorry, been a bit swamped and haven't had a change to dig back into it. Hoping this weekend.

@evocateur
Copy link
Member

@milesj No worries, I completely understand.

@evocateur
Copy link
Member

I force-rebased your changes on top of recent work in master, so be sure to git pull before continuing.

@milesj
Copy link
Contributor Author

milesj commented Feb 7, 2019

@evocateur Thanks for the heads up 👍

@milesj
Copy link
Contributor Author

milesj commented Feb 7, 2019

@evocateur Added tests 👍

owner: "lerna",
repo: "lerna",
tag_name: "v2.0.0",
name: "v2.0.0",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just want to verify this is correct for fixed.

@milesj milesj changed the title WIP: Create GitHub releases when versioning/tagging Create GitHub releases when versioning/tagging Feb 7, 2019
Copy link
Member

@evocateur evocateur left a comment

Choose a reason for hiding this comment

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

Thanks for your patience!

@evocateur evocateur changed the title Create GitHub releases when versioning/tagging feat(version): Create Github releases with --github-release Feb 8, 2019
@evocateur evocateur merged commit f84a631 into lerna:master Feb 8, 2019
@evocateur
Copy link
Member

Hot damn, it worked great!

@milesj milesj deleted the gh-release branch February 8, 2019 03:16
@milesj
Copy link
Contributor Author

milesj commented Feb 8, 2019

@evocateur AWW YESS! Thanks for accepting it, this is awesome.

@ChrisBAshton
Copy link

Amazing work, thanks @milesj !

@tunnckoCore
Copy link

tunnckoCore commented Feb 11, 2019

That's great, but it also generates a CHANGELOG.md. Is it expected or a bug?
When pass --no-changelog, then it does not generate releases too, but in the docs is mentioned that it only requires --conventional-commits.

Or at least, if those files are needed for generating releases, then can we add one more flag to not commit the changelogs after the release is created?

@evocateur
Copy link
Member

@tunnckoCore Yes, currently it is required to write out the changelog files due to the way the code is currently factored:

// generate the markdown for the upcoming release.
const changelogStream = conventionalChangelogCore(options, context, gitRawCommitsOpts);
return Promise.all([
getStream(changelogStream).then(makeBumpOnlyFilter(pkg)),
readExistingChangelog(pkg),
]).then(([newEntry, [changelogFileLoc, changelogContents]]) => {
log.silly(type, "writing new entry: %j", newEntry);
const content = [CHANGELOG_HEADER, newEntry, changelogContents].join(BLANK_LINE);
return fs.writeFile(changelogFileLoc, content.trim() + EOL).then(() => {
log.verbose(type, "wrote", changelogFileLoc);
return {
logPath: changelogFileLoc,
newEntry,
};
});
});
});

The docs aren't wrong, per se, but they are certainly omitting a case. I can add an error when --no-changelog is also passed to make it extra clear.

@tunnckoCore
Copy link

Yea, warning or directly error sounds good.

@evocateur
Copy link
Member

030de9d should do the trick.

@azz
Copy link
Contributor

azz commented Mar 6, 2019

Is there a issue to track supporting --no-changelog with --github-release?

@evocateur
Copy link
Member

evocateur commented Mar 6, 2019 via email

@milesj
Copy link
Contributor Author

milesj commented Mar 6, 2019

@azz Curious how you think that would work?

@azz
Copy link
Contributor

azz commented Mar 6, 2019

I'm not completely across the technical details, but generating both CHANGELOG.md and GitHub releases is duplicate information.

@azz
Copy link
Contributor

azz commented Mar 6, 2019

Raised #1959 to discuss

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants