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
Conversation
@evocateur Sorry for the PR spam, while I stated in the PR before that we found a workaround with 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. |
include-merged-tags
option to changed / version comandinclude-merged-tags
option to changed / version comand
include-merged-tags
option to changed / version comandinclude-merged-tags
option to changed / version comand
include-merged-tags
option to changed / version comandinclude-merged-tags
option to changed / version comand
include-merged-tags
option to changed / version comandinclude-merged-tags
option to changed / version comand
include-merged-tags
option to changed / version comandinclude-merged-tags
option to changed / version command
OK, added docs + tests, one existing test is failing (that I did not touch), not sure why though. |
@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 |
@dzsodzso63 So we found a workaround for |
@HazAT thanks, this made us an idea to check changes like |
@dzsodzso63 I mean I don't see why this shouldn't be merged but it's not in my power ;) |
@evocateur Can you please review this one? |
Hi @HazAT @dzsodzso63 Did you consider rebasing over true merges? Seems to work fine if you rebase your release branch onto master. |
Rebased ♻️ |
@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? |
@dzsodzso63 @danielcondemarin Right, we create the tag in our release branch, rebasing would create a new sha. |
@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) |
@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"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you consider these regarding lightweight tags?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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
commands/changed/command.js
Outdated
@@ -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", { |
There was a problem hiding this comment.
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) => { |
There was a problem hiding this comment.
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.
commands/changed/README.md
Outdated
@@ -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` |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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"); |
There was a problem hiding this comment.
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.
include-merged-tags
option to changed / version commandinclude-merged-tags
option to version command
@evocateur Thanks for your review, I made the changes you requested. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent, thanks!
include-merged-tags
option to version command--include-merged-tags
option
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. |
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:
When running
lerna changed
results in this output: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 togit describe --always --long --dirty --tags
which results in4.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-javascriptMotivation 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
Checklist: