Generate release changelog based on commits

[lexnv]

This script is intended to automate part of the release process.
As stated in the release, the changelog should be created from closed PRs.
In this approach, the script inspects the merged PRs into the main branch origin/master, that is similar to what the substrate repository does.

Testing Done

• shellcheck ./scripts/generate_changelog.sh
• Output without commits

./scripts/generate_changelog.sh
[+] Latest release tag: v0.18.0
[+] Changelog

• Output with commits

./scripts/generate_changelog.sh
[+] Latest release tag: v0.17.0
[+] Changelog

- Release preparation for v0.18.0 ([#464](https://github.com/paritytech/subxt/pull/464))
- Reference key storage api ([#447](https://github.com/paritytech/subxt/pull/447))
- Update scale-info and parity-scale-codec requirements ([#462](https://github.com/paritytech/subxt/pull/462))
- Filter one or multiple events by type from an EventSubscription ([#461](https://github.com/paritytech/subxt/pull/461))
- Distinct handling for N fields + 1 hasher vs N fields + N hashers ([#458](https://github.com/paritytech/subxt/pull/458))
- Substitute BTreeMap/BTreeSet generated types for Vec ([#459](https://github.com/paritytech/subxt/pull/459))
- Obtain DispatchError::Module info dynamically ([#453](https://github.com/paritytech/subxt/pull/453))
- Add hardcoded override to ElectionScore ([#455](https://github.com/paritytech/subxt/pull/455))
- Expose method to fetch nonce via `Client` ([#451](https://github.com/paritytech/subxt/pull/451))
- DispatchError::Module is now a tuple variant in latest Substrate ([#439](https://github.com/paritytech/subxt/pull/439))
- Fix flaky event subscription test ([#450](https://github.com/paritytech/subxt/pull/450))
- Improve documentation ([#449](https://github.com/paritytech/subxt/pull/449))
- New Event Subscription API ([#442](https://github.com/paritytech/subxt/pull/442))
- Export `codegen::TypeGenerator` ([#444](https://github.com/paritytech/subxt/pull/444))
- Fix conversion of `Call` struct names to UpperCamelCase ([#441](https://github.com/paritytech/subxt/pull/441))
- Update release documentation with dry-run ([#435](https://github.com/paritytech/subxt/pull/435))

[niklasad1]

This is really cool but what I would want for subxt is to tag the PRs such that "maintainers and users" can identify which PRs are breaking changes otherwise someone still has go through all commits anyway to ensure nothing breaks since we are following the semver rules anyway.

[jsdw]

I def think this will save us some time so I'm in favour! Manually copying the text and links and making sure the links are correct takes a bunch of time in several of the projects we release (for me at least!)!

I'd be up for following some sort of naming format for PRs (which would you recommend?); it would be easy to manually copy the output from this and group things according to some format we follow, and if we get more rigerous with it then the tool could be tweaked to auto group things also.

[niklasad1]

I think some kind of label system would help a lot such as fixed/bug fix, feature/added, breaking/changed and chore where the reviewer could apply proper labels or something...

Then we could generate a much more readable CHANGELOG because I like having different sections for bug fixes, features and so on :)

[jsdw]

Just to clarify, are you thinking labels as in actual github labels, or as in some text we'd add to PR titles like feature: some new thing?

(I like the idea of both, and actual github labels seem like a great idea, but they would be harder for a tool like this to get hold of I think)

[niklasad1]

I was thinking of Github labels but yeah you are right easier to parse based on commit format than Github labels

[lexnv]

The idea to automate completely the changelog seems like a great one!

I do think that both options are really good in terms of outcome, but I tend to lean towards the labeling format.
Just because it gives a bit of extra flexibility when it comes to development, not enforcing us to a pattern of commit messages.

We could do something like curl https://api.github.com/repos/paritytech/subxt/pulls/204 and then parse the output with jq to fetch the labels that we are interested in, which is indeed a bit more complex than matching the commit message.

[dvdplm]

The idea to automate completely the changelog seems like a great one!

I think it would be terrific if it works but I don't think it's realistic to get there in a single leap. I think we should instead aim to automate the information collection and save as many manual steps as possible while still allowing for manual intervention. People forget labels (looking at myself here!) and relying on commit message or PR title formatting is too brittle.

There's a proposal for substrate labels reform up on Notion. I think it'd be good to await the evolution of that and once they're happy we should adopt the same set of labels to start normalizing things across all repos.

In other words, I think we should do this step by step and this PR seems like a great first step!

[jsdw]

It looks like verify-tag is all about verifyingthe signature of the tag is valid, so perhaps the log_error could be more descriptive eg "Failed to verify tag; bad signature"?

[jsdw]

Looks clean and works for me; nice one :)

As @dvdplm said I think this is a great first step, and it'll already save some time!

[dvdplm]

We need instructions on how to use this in the RELEASING file.

[dvdplm]

Need a usage example here (and/or print the help when args are missing?)