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): Add --include-merged-tags option #1712

Merged
merged 5 commits into from Nov 27, 2018
Merged

Conversation

HazAT
Copy link
Contributor

@HazAT HazAT commented Oct 2, 2018

Description

Disclaimer:
This is the successor PR to
#1704

lerna fails to detect/consider tags from merged branches.
This results in that if you tag for example on a release branch, lerna changed returns all changes until the last tag of the current branch.

Let's say you have the following setup:
screenshot 2018-09-28 13 29 06

When running lerna changed results in this output:

yarn lerna changed
yarn run v1.3.2
$ /Users/haza/Projects/sentry-javascript/node_modules/.bin/lerna changed
lerna notice cli v3.4.0
lerna info Looking for changed packages since 4.0.5
@sentry/browser
@sentry/core
@sentry/hub
@sentry/minimal
@sentry/node
@sentry/types
@sentry/utils
lerna success found 7 packages ready to publish
✨  Done in 0.95s.

When clearly there is a merged release branch with version 4.0.6.
It's still true that 4.0.5 was tagged on the master branch.

lerna runs following command under the hood: git describe --always --long --dirty --first-parent which returns: 4.0.5-9-g89885fae which is correct but not taking tags on other branches into the calculation.

A new option include-merged-tags therefore was added to support tags from merged branches.
It changes the previous git describe command to
git describe --always --long --dirty --tags which results in 4.0.6-8-g6fbeff9a which in the example stated above is correct.

We are using lerna for our javascript SDKs https://github.com/getsentry/sentry-javascript

Motivation and Context

We think that tagging in a release branch should be a valid scenario the lerna should be able to support. Right now the only way to work around this limitation is if we would work around lerna for bumping and releasing.

How Has This Been Tested?

Locally in our repo + added test cases highlighting the new behavior.

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.

@HazAT
Copy link
Contributor Author

HazAT commented Oct 2, 2018

@evocateur Sorry for the PR spam, while I stated in the PR before that we found a workaround with --since which is true to basically replace lerna changed but it's not allowing us to use lerna version.

This PR is still WIP I just want to know if you consider merging this new feature at all, if so please let me know I will finish the PR (write tests + docs for the new option).

Thanks for your time and the great project.

@HazAT HazAT changed the title [WIP] Add include-merged-tags option to changed / version comand [WIP] feat(changes/version): Add include-merged-tags option to changed / version comand Oct 2, 2018
@HazAT HazAT changed the title [WIP] feat(changes/version): Add include-merged-tags option to changed / version comand WIP: feat(changes/version): Add include-merged-tags option to changed / version comand Oct 2, 2018
@HazAT HazAT changed the title WIP: feat(changes/version): Add include-merged-tags option to changed / version comand WIP: feat(changed/version): Add include-merged-tags option to changed / version comand Oct 2, 2018
@HazAT HazAT changed the title WIP: feat(changed/version): Add include-merged-tags option to changed / version comand feat(changed/version): Add include-merged-tags option to changed / version comand Oct 9, 2018
@HazAT HazAT changed the title feat(changed/version): Add include-merged-tags option to changed / version comand feat(changed/version): Add include-merged-tags option to changed / version command Oct 9, 2018
@HazAT
Copy link
Contributor Author

HazAT commented Oct 9, 2018

OK, added docs + tests, one existing test is failing (that I did not touch), not sure why though.

@dzsodzso63
Copy link

Sorry for the PR spam, while I stated in the PR before that we found a workaround with --since which is true to basically replace lerna changed but it's not allowing us to use lerna version.

@HazAT can you please explain this "workaround"? we have this issue since upgrading to lerna 3, that we cannot determine changed packages because of the --first-parent param (publish from release branches + PR), but --since switch doesn't work since lerna 3. What we should do?

@HazAT
Copy link
Contributor Author

HazAT commented Oct 16, 2018

@dzsodzso63 So we found a workaround for changed, using --since
yarn lerna exec --since $(git rev-list --tags --max-count=1) pwd
But it doesn't work for version / publish so right now we are using my fork right now.

@dzsodzso63
Copy link

@HazAT thanks, this made us an idea to check changes like
lerna exec --since $(git rev-list --tags --max-count=1) --loglevel=silent -- npm v . name
but the real win would be this PR merged (we now can scope down other processes (e.g. tests), but we publish everything on each merge).
Do you think this merge can happen sometime?

@HazAT
Copy link
Contributor Author

HazAT commented Oct 16, 2018

@dzsodzso63 I mean I don't see why this shouldn't be merged but it's not in my power ;)
I am happy to do anything to get this merged since we also don't want to rely on my fork for this ^^

@dzsodzso63
Copy link

@evocateur Can you please review this one?

@danielcondemarin
Copy link
Contributor

Hi @HazAT @dzsodzso63 Did you consider rebasing over true merges? Seems to work fine if you rebase your release branch onto master.

@HazAT
Copy link
Contributor Author

HazAT commented Oct 29, 2018

Rebased ♻️

@zhusee2 zhusee2 mentioned this pull request Oct 30, 2018
8 tasks
@dzsodzso63
Copy link

dzsodzso63 commented Oct 30, 2018

Hi @HazAT @dzsodzso63 Did you consider rebasing over true merges? Seems to work fine if you rebase your release branch onto master.

@danielcondemarin Maybe I missing something here, but in my understanding, when I rebase the publisher branch to master, then the sha changes, so the tags created by lerna will point to non-existing commits. What do I miss?

@HazAT
Copy link
Contributor Author

HazAT commented Oct 30, 2018

@dzsodzso63 @danielcondemarin Right, we create the tag in our release branch, rebasing would create a new sha.
We really want to have a "snapshot" of the tagged commit that we built.
While rebasing and tagging afterward will probably work 99% of the time we run all tests on this specific commit/tag and want to release it without building it again.

@dzsodzso63
Copy link

@HazAT ok, then we are on the same page (and we cannot even think about publishing after merge, as we have protected master branch and we cannot commit to that directly)

@HazAT
Copy link
Contributor Author

HazAT commented Nov 15, 2018

@evocateur Is there anything left to do for this getting merged?

// we want to consider all tags, also from merged branches
args = args.filter(arg => arg !== "--first-parent");
// also include lightweight tags
args.push("--tags");

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This doesn't really work for our case. As explained we want to tag in a release branch that gets merged into master. But the tagged commit is on the branch.

Choose a reason for hiding this comment

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

I only want to point to the fact that lightweight tags aren't coompatible with lerna and it seems that it will hard to land this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see but it isn't really just a lightweight tag, right?

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 not going to fly. Lightweight tags are not intended to be used for tagging releases.

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.

I like this approach, sorry for the delay in review

@@ -15,7 +15,13 @@ exports.describe = "List local packages that have changed since the last tagged
exports.builder = yargs => {
listable.options(yargs);

return versionOptions(yargs, "changed");
const newYargs = versionOptions(yargs, "changed");
newYargs.option("include-merged-tags", {
Copy link
Member

Choose a reason for hiding this comment

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

Since this was already added in commands/version/command.js, you don't need to duplicate it here? versionOptions() was designed to avoid this duplication. It is hidden, true, but it still works.

@@ -41,6 +44,26 @@ const setupGitChanges = async (cwd, filePaths) => {
await gitCommit(cwd, "Commit");
};

const setupGitChangesWithBranch = async (cwd, masterPaths, branchPaths) => {
Copy link
Member

Choose a reason for hiding this comment

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

This helper and the tests should be moved to a focused test file under the version command, as described previously. lerna changed is just a lightweight wrapper around the internals used by lerna version, it doesn't have any logic itself beyond the list output options.

@@ -27,3 +27,12 @@ package-2
Unlike `lerna ls`, however, `lerna changed` **does not** support [filter options](https://www.npmjs.com/package/@lerna/filter-options), as filtering is not supported by `lerna version` or `lerna publish`.

`lerna changed` also supports all the flags supported by [`lerna version`](https://github.com/lerna/lerna/tree/master/commands/version#options), but the only relevant one is [`--ignore-changes`](https://github.com/lerna/lerna/tree/master/commands/version#--ignore-changes).

### `--include-merged-tags`
Copy link
Member

Choose a reason for hiding this comment

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

This duplicated options block is not necessary. Adding a link to the docs under commands/version directly is fine.


const execa = require("execa");

module.exports = gitCheckout;
Copy link
Member

Choose a reason for hiding this comment

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

Thanks for these helpers, they are handy :)

// we want to consider all tags, also from merged branches
args = args.filter(arg => arg !== "--first-parent");
// also include lightweight tags
args.push("--tags");
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 not going to fly. Lightweight tags are not intended to be used for tagging releases.

@HazAT HazAT changed the title feat(changed/version): Add include-merged-tags option to changed / version command feat(version): Add include-merged-tags option to version command Nov 27, 2018
@HazAT
Copy link
Contributor Author

HazAT commented Nov 27, 2018

@evocateur Thanks for your review, I made the changes you requested.

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.

Excellent, thanks!

@lock
Copy link

lock bot commented Jan 26, 2019

This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants