Generating release changelog from non-master branch commit history

[durera]

We have a system where the latest major release is always from master branch, but we also maintain old major releases in branches such v1.x, v2.x etc, etc. If I run gren for a release from master everything works as I'd expect. The release notes for the latest major release are generated and include all the commits from master branch, but if I want to make a new oldversion.x.y release I can't work out how to make gren use the commits from the appropriate branch rather than master. I couldn't see anything in the docs: https://github-tools.github.io/github-release-notes/options.html

Is this possible and I've just overlooked the option I need?

Invoking gren like this FWIW:

$GREN \
  --username=$USER \
  --repo=$REPO \
  --token=$GITHUB_TOKEN \
  --data-source=commits \
  --action=release \
  --tags=$VERSION \
  --include-messages=commits

[alexcanessa]

Hello @durera, there aren't any options to choose a branch right now. I think is a very good idea tho!

Definitely going into the backlog 🎉

[durera]

Great, I’ll have a look and try wing a PR your way .. I suspect it’s relatively simply change involving adding the sha=branchname param in the method in gren that looks up the commits and defaulting to master when not set.

[alexcanessa]

@durera indeed, all the options coming from the command are in /lib/_option.js (same source utilised for documentation and application).

See how it goes :)

[kstolte]

@durera did you make any progress on this by chance?

[franzwilhelm]

@durera any updates on this?

[cjbarth]

I'm running in to this problem, but a slightly different flavor. I have a branch for the 2.x series of releases and the current 3.x releases are on master. The changelog shows PRs that landed on on master as being part of the 2.x series, which means they aren't showing up on the 3.x series. Given this includes some breaking changes being attributed to the wrong release, this is a real problem.

[cjbarth]

It seems that the correct solution would be to return the entire set of PRs (commits, whatever) that follows the same base.ref. This way you'll get all the commits in the same branch. Thoughts on this approach @alexcanessa ?

[cjbarth]

Further testing and experimentation indicates that the only way to reliably do this would be to take the two tags in the range object and make another API call /repos/{owner}/{repo}/compare/{basehead}. Then, you can either use the list of commits directly from that call, or match the sha from the commits to the ones returned in the call to getMergedPullRequests in order to correctly figure out what is actually in each release.

I'd love to hear from some maintainers if such an approach will land in this project.

[RobAustin]

I think this project may do what you are looking for https://github.com/OpenHFT/Chronicle-Release-Notes

[cjbarth]

Thank you for the suggestion, however, that requires Java, so isn't really an option. I've actually got everything working and am just waiting on some PRs to be approved and landed.