proposal: ci improvements

[stevenh]

What do we think about improving the CI so we have to do less work, a few things come to mind:

1. Adopt conventional commits
2. Fully automate the release process, would require conventional commits
3. Remove CHANGELOG.md, as this will be covered by the generated releases and is just manual overhead

[nvuillam]

I see the advantages of what you propose, but from experience I prefer to have less restrictions on commits, and I prefer changelog.md to be written manually

• Occasional contributors won't think to follow conventional commits, so their PR will fail more often
• Changelog can be organized in a "marketing way" , not a "technical way" (example of how I organize it with MegaLinter)

With current process it takes 5 minutes to make a new release (and it's 95% automated thanks to CI), and you have my full trust to perform them so if you want we can make a call next time i make one :)

[echoix]

I'm curious about the outcome of this, as if it works well, we could try it. The conventional commits requirements could be limited to the title of the commit when the maintainer does a squash and merge of a PR, or to update the title of the PR? If only this has to be changed, it could be great. Or if it uses labels to do the job it could be easy too.

[stevenh]

I've had great success with it, both with teams I've run and in open source.

It produces consistently high quality release notes with pretty much zero effort, you can see an example of this on redigo another open source repo I maintain.

As @echoix said you can avoid blocking contributors by the maintainer amending the commit during merge, which is exactly I do on redigo, but this could also be a none failing test to encourage contributors to submit PR's with the correct setup.

Having the changelog in repo means extra steps for the committer or maintainer or both. I know I've forgotten and had to go back and revise just about every PR. It also results in commit churn with the info from the commits themselves recorded twice, typically in slightly different ways, especially when you amend details as a fix / feature evolves resulting in busy work when the same info has to be edited in two different places.

Another benefit of the automatic approach is that links to PR's and their commits are automatically generated, which is helpful for users if they suspect an issue with a change or even if they want to find out more, all very useful.

In the same vain we could also eliminate the duplication of files under docs.

Thoughts?

[stevenh]

Forgot to mention the release process for redigo is to create a new tag, no details needed, the github action does everything else from filling in the release notes to building the release, so human effort takes about 10 seconds.

[nvuillam]

@stevenh as a part of me has a touch of "marketing", I still prefer manually written changelogs, but as we are in maintenance , the information probably does not need to be manually refactored (and even if it did, it can be done by manually updating the release after)

And anyway I'm so happy that you fell from the sky to save the project that I can't refuse you anything 🤣 , so you have my go for :

• Switching to conventional commits & auto-generation
• Well documenting the new process (knowing your style I know you will ^^)

Please just keep the manual validation (by one of us with environment management) for the release GH Workflow , I find it more secure :)

[stevenh]

Thanks for the vote of confidence @nvuillam appreciate it. I'll look at what currently exists see what's in play and what the best options are for npm repo.

I can confirm that once created by the action you can manually edit at any point, so if you want to customise, that's really easy.

[stevenh]

Think the bot is a bit keen