Automatically create a changelog from the git history

[adamsardar]

As a developer contributing to a project
I want for my changelog to be automatically generated from my git commit messages
So that I have all the benefits of keeping a changelog, but don't have the arduous faff of documenting what I've done separately from my git messages.

Currently I have to pre-empt a 'tag-to-deploy' stage with a PR. If this was dynamically compiled, then I wouldn't have to write anything extra. DRY and all.

Not all commits should go into the changelog; just posh ones that have been marked-up appropriately.

This would force us to improve our git commit message disciple on the project. Since the commit message is part of the commit hash, once a commit is on main we cannot alter it. Consider compiling the contribution to a new changelog that a PR would add so that it can be part of the review?

Suggestions

I think that git-cliff is what we want here. Customisable and fast - there's even a github action

[adamsardar]

Some stages to fulfilling this item:

• Add git-cliff config to repo (via pyproject.toml - see All configs within pyproject.toml for a streamlined build experience #256)
• Consider expanding the default regexes (some developers use gitmojis; add these to the regexes). Since they are a subset of unicode emojis, this is effectively a regex for emojis.
• Add links to gh tubular issues and PRs
• Splice changelog output ontop of the existing CHANGELOG.rst. Try to match the format that we already use (keep a changelog 'format')
• Include guidance in the CONTRIBUTING.rst doc
• Consider autogenerating a contributors list from the git history?
• Add a tool that shows the CHANGELOG delta from just the commits on a branch. Is there away to add this to a PR automatically?

I think that we should then let the above processes bed in before enabling a stage that automatically compiles a CHANGELOG for the project as part of CD. Creating a CHANGELOG would therefore still be a manual process, but could be assisted by git-cliff.

[adamsardar]

Note, implementing this ticket would prove an alternative to #165 in the long run