gh changelog new gets confused if there are multiple branches

[joshcooper]

Hi @chelnak, the gh changelog new command seems to get confused if there multiple active branches and tags.

For example, https://github.com/puppetlabs/facter only has one active branch (main), so this works:

❯ gh changelog new --from-version 4.6.0 --next-version 4.7.1
❯ cat CHANGELOG.md
...
## [4.7.0](https://github.com/puppetlabs/facter/tree/4.7.0) - 2024-04-09

[Full Changelog](https://github.com/puppetlabs/facter/compare/4.6.1...4.7.0)
...

But puppet has two active branches. If I'm on main, then this doesn't work:

❯ gh changelog new --from-version 7.29.1 --next-version 7.30.1
⠦ Fetching tags...
❌ It looks like something went wrong!

Reported errors:
• the next version should be greater than the former: '7.30.1' ≤ '8.6.0'

And neither does checking out the 7.x branch:

❯ git checkout 7.x
Branch '7.x' set up to track remote branch '7.x' from 'origin'.
Switched to a new branch '7.x'
❯ gh changelog new --from-version 7.29.1 --next-version 7.30.1
⠴ Fetching tags...
❌ It looks like something went wrong!

Reported errors:
• the next version should be greater than the former: '7.30.1' ≤ '8.6.0'

If I remove --next-version, then it generates the changelog, but interleaves the tags from different branches:

❯ gh changelog new --from-version 7.29.1                      
✓ Open CHANGELOG.md or run 'gh changelog show' to view your changelog.

❯ cat CHANGELOG.md 
...
[Full Changelog](https://github.com/puppetlabs/puppet/compare/8.5.1...7.30.0)

Note the last line going from 8.5.1...7.30.0. For example, git knows 8.5.1 is not an ancestor of 7.x, but is of main:

❯ git merge-base --is-ancestor 8.5.1 7.x
❯ echo $?
1
❯ git merge-base --is-ancestor 7.30.0 7.x 
❯ echo $?
0

I was hoping gh changelog new would only report on pull requests whose merge commits are contained within the specified --from-version to --next-version range.

I don't believe this is a dup of #144 (but maybe related)?

[chelnak]

Hey @joshcooper ! It's been a while. Hope you are well.

It looks like I missed something when I originally built the extension.. I mainly used the module repos as test cases and they only tag on main.

Life/Work has been a bit crazy this month so haven't had much mental capacity to dedicate to my open source stuff. However I'll free some time to look at this and #144 this week. I'll do what I can to get you folks up and running. 🙂

[chelnak]

👋 Your test using merge-base was really helpful, and I was able to add a patch that filters based on the exit code of the command.

The extension only looks at tags for the repo and not the specific commits associated with a branch, so pretty sure this is why you are seeing the strange results.

I used your examples as test cases..

Example 1 on main:

❯ gh changelog new --from-version 7.29.1 --next-version 7.30.1
⠦ Fetching tags...
❌ It looks like something went wrong!

Reported errors:
• the next version should be greater than the former: '7.30.1' ≤ '8.6.0'

I think this is the right result, because --next-version is the version that you are releasing.. because 7.30.1 is less than 8.6.0 (the latest tag), it fails for this branch.

However, as you mention when you run without --next-version it still includes incorrect tags. I expected the merge-base patch to help, but it still includes some 7.x tags.

For example, with gh changelog new --from-version 8.0.0 --next-version 8.6.1 you can see that we still get 7.x tags referenced.

Example 2 on 7.x

❯ git checkout 7.x
Branch '7.x' set up to track remote branch '7.x' from 'origin'.
Switched to a new branch '7.x'
❯ gh changelog new --from-version 7.29.1 --next-version 7.30.1
⠴ Fetching tags...
❌ It looks like something went wrong!

Reported errors:
• the next version should be greater than the former: '7.30.1' ≤ '8.6.0'

With the patch using merge-base, it creates what looks like a reasonable changelog:

I'm trying to make sense of this (slowly), so will test out a few more things and post back soon.

[chelnak]

Hey @joshcooper

So I've been playing around with this quite a bit.

As i mentioned above, i'm now using merge-base to determine if a tag is an ancestor of the current branch. Also, i've added a filter flag that allows you to filter out entries matching a given regex.

So for example, on puppets main branch:

gh changelog new --from-version 8.0.0 --next-version 8.6.1 --filter 7.*

Gives me what looks like a reasonable output of tags for puppet 8.

## [8.6.1](https://github.com/puppet/puppet/tree/8.6.1) - 2024-04-20

[Full Changelog](https://github.com/puppet/puppet/compare/8.6.0...8.6.1)

## [8.6.0](https://github.com/puppet/puppet/tree/8.6.0) - 2024-04-09

[Full Changelog](https://github.com/puppet/puppet/compare/8.5.1...8.6.0)

## [8.5.1](https://github.com/puppet/puppet/tree/8.5.1) - 2024-03-04

[Full Changelog](https://github.com/puppet/puppet/compare/8.5.0...8.5.1)

## [8.5.0](https://github.com/puppet/puppet/tree/8.5.0) - 2024-02-26

[Full Changelog](https://github.com/puppet/puppet/compare/8.4.0...8.5.0)

## [8.4.0](https://github.com/puppet/puppet/tree/8.4.0) - 2024-01-16

[Full Changelog](https://github.com/puppet/puppet/compare/8.3.1...8.4.0)

## [8.3.1](https://github.com/puppet/puppet/tree/8.3.1) - 2023-10-26

[Full Changelog](https://github.com/puppet/puppet/compare/8.3.0...8.3.1)

## [8.3.0](https://github.com/puppet/puppet/tree/8.3.0) - 2023-10-25

[Full Changelog](https://github.com/puppet/puppet/compare/8.2.0...8.3.0)

## [8.2.0](https://github.com/puppet/puppet/tree/8.2.0) - 2023-08-22

[Full Changelog](https://github.com/puppet/puppet/compare/8.1.0...8.2.0)

## [8.1.0](https://github.com/puppet/puppet/tree/8.1.0) - 2023-06-13

[Full Changelog](https://github.com/puppet/puppet/compare/8.0.1...8.1.0)

## [8.0.1](https://github.com/puppet/puppet/tree/8.0.1) - 2023-04-26

[Full Changelog](https://github.com/puppet/puppet/compare/54e9b5e3561977ea063417da12c46aad2a4c1332...8.0.1)

Does this align with behaviour you expected?

[h0tw1r3]

I think the problem is simply a limitation of the GH tag rest api. Doesn't seem to allow you to restrict the returned tags to just those associated to a specific branch.

Would it be worth re-working the gitclient/go GetTags function to search the local repo? This works a treat for annotated tags:

git for-each-ref refs/tags --sort='-taggerdate' --format='%(refname:short)' --merged=HEAD

Or this for all tags:

git for-each-ref refs/tags --sort='-*creatordate' --format='%(refname:short)' --merged=HEAD

[h0tw1r3]

I also think the --filter argument is a good idea too if it could take a regexp