--changelog-include-commits-client-login doesn't work with independent mode

[StarpTech]

Describe the bug

Hello,
I try

GH_TOKEN=ghp_secret lerna version --conventional-commits --changelog-include-commits-client-login --create-release github --git-dry-run

and it generate this

? Are you sure you want to create these versions? Yes
lerna-lite verb independent wrote /home/starptech/repositories/wundergraph/wundergraph/packages/sdk/CHANGELOG.md
lerna-lite verb independent wrote /home/starptech/repositories/wundergraph/wundergraph/packages/nextjs/CHANGELOG.md
lerna-lite info dry-run> git add -- packages/sdk/package.json packages/sdk/CHANGELOG.md packages/nextjs/package.json packages/nextjs/CHANGELOG.md
lerna-lite verb git commit -F /tmp/126f273a-186a-4603-8ca0-0677638e0833/lerna-commit.txt
lerna-lite info dry-run> git commit -F /tmp/126f273a-186a-4603-8ca0-0677638e0833/lerna-commit.txt
lerna-lite verb git tag @wundergraph/nextjs@0.1.1 -m @wundergraph/nextjs@0.1.1
lerna-lite info dry-run> git tag @wundergraph/nextjs@0.1.1 -m @wundergraph/nextjs@0.1.1
lerna-lite verb git tag @wundergraph/sdk@0.98.0 -m @wundergraph/sdk@0.98.0
lerna-lite info dry-run> git tag @wundergraph/sdk@0.98.0 -m @wundergraph/sdk@0.98.0
lerna-lite info git Pushing tags...
lerna-lite info dry-run> git push --follow-tags --no-verify --atomic origin main
lerna-lite info execute Creating releases...
lerna-lite verb git config --get remote.origin.url
lerna-lite info dry-run> Create Release with repo options:  {"owner":"wundergraph","repo":"wundergraph","tag_name":"@wundergraph/sdk@0.98.0","name":"@wundergraph/sdk@0.98.0","body":"## [0.98.0](https://github.com/wundergraph/wundergraph/compare/@wundergraph/sdk@0.97.0...@wundergraph/sdk@0.98.0) (2022-08-18)\n\n\n### Features\n\n* native webhooks support ([#126](https://github.com/wundergraph/wundergraph/issues/126)) ([a0b38bd](https://github.com/wundergraph/wundergraph/commit/a0b38bd54b88198db6cc176432d577dab0931245))\n\n\n### Bug Fixes\n\n* issue with unhandled hyphens in input names ([#123](https://github.com/wundergraph/wundergraph/issues/123)) ([b01caaa](https://github.com/wundergraph/wundergraph/commit/b01caaa8c4036afbeb579dbbf14a52d82971b116))\n\n","draft":false,"prerelease":false}
lerna-lite info dry-run> Create Release with repo options:  {"owner":"wundergraph","repo":"wundergraph","tag_name":"@wundergraph/nextjs@0.1.1","name":"@wundergraph/nextjs@0.1.1","body":"## [0.1.1](https://github.com/wundergraph/wundergraph/compare/@wundergraph/nextjs@0.1.0...@wundergraph/nextjs@0.1.1) (2022-08-18)\n\n**Note:** Version bump only for package @wundergraph/nextjs\n\n\n\n","draft":false,"prerelease":false}
lerna-lite success version finished

same as without the flag

## [0.98.0](https://github.com/wundergraph/wundergraph/compare/@wundergraph/sdk@0.97.0...@wundergraph/sdk@0.98.0) (2022-08-18)

### Features

* native webhooks support ([#126](https://github.com/wundergraph/wundergraph/issues/126)) ([a0b38bd](https://github.com/wundergraph/wundergraph/commit/a0b38bd54b88198db6cc176432d577dab0931245))

### Bug Fixes

* issue with unhandled hyphens in input names ([#123](https://github.com/wundergraph/wundergraph/issues/123)) ([b01caaa](https://github.com/wundergraph/wundergraph/commit/b01caaa8c4036afbeb579dbbf14a52d82971b116))

Expectation

Should add the authors to the changelog as described in https://github.com/ghiscoding/lerna-lite/tree/main/packages/version#--changelog-include-commits-client-login-msg

Reproduction

See above.

Lerna config and logs

lerna.json

<!-- Please paste your `lerna.json` here -->

lerna-debug.log

<!-- If you have a `lerna-debug.log` available, please paste it here -->
<!-- Otherwise, feel free to delete this <details> block -->

Environment Info

| Executable        | Version |
| ----------------- | ------- |
| `lerna --version` | 1.10.0 |
| `npm --version`   | VERSION |
| `yarn --version`  | VERSION |
| `node --version`  | VERSION |

---
OR simply run `npx lerna info` command and copy+paste the result here

Used Package Manager

pnpm

Validations

• Follow our Code of Conduct
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion.
• The provided reproduction is a minimal reproducible example of the bug.

[ghiscoding]

it works flawlessly with my repos, the only possible reason that this might not work would be that it doesn't pull the correct date of the last release (it might also be affected by the branch you are in) OR that your local branch is not in sync with origin (GitHub) because if it's not then it won't return anything. This feature works a lot better when executed from the main branch when it is in sync with GitHub

The reason I use the date is mostly because the GitHub API has a limit of max 100 results per query. The method which tries to find the last release date is the following (perhaps I should add log.info of the date that was found). You can run the git command as shown below or change your log level to silly to find out what date was returned

https://github.com/ghiscoding/lerna-lite/blob/f20f1ba58605b69c3171855429d7826daab25818/packages/core/src/conventional-commits/get-commits-since-last-release.ts#L39-L69

from that date, it will then run the GraphQL query from the GitHub API (which you can try yourself with the GitHub GraphQL Explorer)

https://github.com/ghiscoding/lerna-lite/blob/f20f1ba58605b69c3171855429d7826daab25818/packages/core/src/conventional-commits/get-github-commits.ts#L31-L42

Also note that it is relying a lot on the last release date, if you happen to do a pre-release and then the same day do a master release, then it won't find anything because the last date found would be the pre-release date. There isn't much I can do about that part, unless I add an extra option to manually provide the date to query from (but it has to follow the git timestamp format for it to work in the graphql query)

[StarpTech]

I tried it on main. I also double-checked that I pulled the latest changes.

[ghiscoding]

please follow the instruction I gave you to troubleshoot it, I can't help without them executed first

basically run this git command to find out what is the last release date it found and then run the GrahpQL query

git log {lastTagName}..HEAD --format="%h %aI" --reverse

hmm actually this last tag name might be the problem since I know you use the independent tag and I'm not, it probably won't find the correct date in that case

[StarpTech]

I have a monorepo with two different tag formats. Do you remember my PR #222 Maybe your forgot to add this here as well?

hmm actually this last tag name might be the problem since I know you use the independent tag and I'm not, it probably won't find the correct date in that case

Yes, https://github.com/wundergraph/wundergraph/blob/main/lerna.json

git log {lastTagName}..HEAD --format="%h %aI" --reverse

e616499 2022-08-09T13:59:14+02:00
f3fdf58 2022-08-09T14:11:21+02:00
3ca532f 2022-08-15T10:47:23+02:00
b01caaa 2022-08-15T10:21:16-04:00
d7589d8 2022-08-16T10:23:56-07:00
0020f05 2022-08-18T12:10:12+02:00
a0b38bd 2022-08-18T19:13:55+02:00
5cc00c2 2022-08-18T19:23:51+02:00
63fc5bc 2022-08-18T19:37:17+02:00
c958df4 2022-08-18T19:52:00+02:00
0e2def4 2022-08-18T19:53:32+02:00
d0dc2e4 2022-08-18T19:56:11+02:00
822b9c1 2022-08-18T20:03:33+02:00
66101e7 2022-08-18T20:19:26+02:00
bcd9109 2022-08-18T20:25:24+02:00
(END)

[ghiscoding]

from the reverse list, it will only use the top most date (first one), you then take that date (without the left hash) and you put it into the GitHub GraphQL query that is shown on top.

but again I think the issue is probably because you're using independent versions and I'm not and in that case how to pull the date, I'm also not sure what is the tag name used in this case for that git command. It looks like I forgot to add any kind of log about the date found, I'll take a look at adding that latest tonight or tomorrow and possibly a new option to provide a manual date, the git command to find last tag is executed from the describeRef method which seem to be executing this git command (which I guess would have returned @wundergraph/sdk@0.97.0 in your case)

git describe --always --long --dirty --first-parent

https://github.com/ghiscoding/lerna-lite/blob/f20f1ba58605b69c3171855429d7826daab25818/packages/core/src/utils/describe-ref.ts#L41

I'm really not sure what would be the result when using independent mode, but I'm pretty sure it's related to that. If you have any suggestions on how to get the last release date other than I posted, then provide your suggestion (typically a git command)

[StarpTech]

git describe --always --long --dirty --first-parent

returns the wrong tag v0.99.0-2-g1f063cc because as mentioned above I have two different tag pattern in the repo. In independent mode it should only search for *@* As in https://github.com/ghiscoding/lerna-lite/blob/f20f1ba58605b69c3171855429d7826daab25818/packages/core/src/utils/collect-updates/collect-updates.ts#L40

[ghiscoding]

so if you know what git command to execute to get the last release date from the last git tag then please propose suggestion. The only thing it really does is to find the last release date, perhaps finding the last git tag to then find the last release date is too cumbersome. It was working fine with fixed versions, but I'm not sure this is really the best thing to do in independent mode. Do you have other suggestions to find the last github release date?

I could add some of these options, but I would rather not add too many options for no big reason

• manually provide release date
• manually provide tag name

[StarpTech]

I will take a deeper look and let you know.

[ghiscoding]

If you want to take a look, all the code I added for this feature were added into these 2 new files

• get-commits-since-last-release.ts
• get-github-commits.ts
• describe-ref.ts is used to pull the last tag name, if you have a better git command to find last tag in your environment then we can skip the describeRef and simply go with a git command

which is then used in the update-changelog.ts

Perhaps another thing I could do would be to add a prompt to ask the user (you) which tag to start querying from, but that would require a lot more code I guess. I would prefer to go without it if possible but that could be a last resource option

[ghiscoding]

returns the wrong tag v0.99.0-2-g1f063cc because as mentioned above I have two different tag pattern in the repo. In independent mode it should only search for *@* As in

https://github.com/ghiscoding/lerna-lite/blob/f20f1ba58605b69c3171855429d7826daab25818/packages/core/src/utils/collect-updates/collect-updates.ts#L40

oh by looking at the code you referenced, I think I found the way to fix this as you highlighted, a few lines below it does add describeOptions.match = tagPattern; when using independent mode, which I did not use in my code to get tag.

https://github.com/ghiscoding/lerna-lite/blob/f20f1ba58605b69c3171855429d7826daab25818/packages/core/src/utils/collect-updates/collect-updates.ts#L40-L49

So I guess this code change would probably work

const describeOptions: DescribeRefOptions = { ...execOpts };
+ if (isIndependent) {
+   describeOptions.match = tagPattern;
+ }
const { lastTagName } = describeRefSync(describeOptions, includeMergedTags);

instead of
https://github.com/ghiscoding/lerna-lite/blob/f20f1ba58605b69c3171855429d7826daab25818/packages/core/src/conventional-commits/get-commits-since-last-release.ts#L45-L48

however the isIndependent would have to be provided to the method, something like you did in your previous PR.

Would you like to submit a PR?

[ghiscoding]

closed by PR #311

@StarpTech
I pushed a fix and a new release v1.11.0, you can give that a try, I assume that it would work. It would be nice to get confirmation, since I could not test it because I don't personally use independent in any of my repos. Thanks

[StarpTech]

Thank you!

[StarpTech]

Hi, @ghiscoding I found the issue. With the latest version it works but --changelog-include-commits-client-login is interpreted as an empty string and therefore false in all comparisons. When I define a custom template like @%l it goes through 😄

[ghiscoding]

oh you mean it's not treated as a proper boolean, I'll have to take a look then, I also use it with a template so I might have missed that. I'll reopen the issue then, it should be a quick fix if it's just a boolean problem

[StarpTech]

oh you mean it's not treated as a proper boolean, I'll have to take a look then, I also use it with a template so I might have missed that.

Exactly