Meta: prefix dependabot PRs with 'Meta'
Check list
- [X] I have performed a self-review of my code
- [ ] I have commented my code in hard-to-understand areas
- [ ] I have added unit tests for my code
- [ ] I have made corresponding changes to the documentation
Description
We currently use the prefix 'Meta' to ignore commits from turning up in the changelog and triggering releases. We use dependabot exclusively to bump GitHub actions and these commits should never trigger a release. By default dependabot uses the prefix 'Chore(deps)', which caused unnecessary releases being created in the past. This PR changes the commits from depandabot to use the prefix 'Meta' instead.
Type of change
- [ ] Bug fix
- [ ] New feature
- [ ] Refactor
- [ ] Breaking change
- [ ] Test
- [ ] Documentation change
- [X] CI
Test environment
- Shell
- [ ] bash
- [ ] zsh
- [ ] fish
- OS
- [ ] Linux
- [ ] Mac OS X
- [ ] Windows
- [ ] Others:
Failing tests are fixed with #480
Thanks for the good idea @sandr01d. I would like to use this to start a discussion whether we should switch to conventional commits instead. When I implemented the release notes script, I was not aware of the conventional commits concept, so I just came up with the "Meta" prefix myself as a solution for excluding commits from the changelog.
When using conventional commits, we could as well use existing GitHub actions for generating the changelog, e.g. this one. If I were to set up automatic GitHub releases for forgit today, I would actually go this route, as it aligns with common practices instead of building a custom solution.
Let me know what you guys think. @sandr01d @cjappl @wfxr
I'm all for conventional commits. I've been using them at work for the past year and find them very useful. Regarding automated changelog generation, I've had a very good experience using git-cliff. It supports conventional commits and has a GitHub Action too. We could also use commitlint to enforce conventional commits through the CI.
Thanks for the good idea @sandr01d. I would like to use this to start a discussion whether we should switch to conventional commits instead. When I implemented the release notes script, I was not aware of the conventional commits concept, so I just came up with the "Meta" prefix myself as a solution for excluding commits from the changelog.
When using conventional commits, we could as well use existing GitHub actions for generating the changelog, e.g. this one. If I were to set up automatic GitHub releases for forgit today, I would actually go this route, as it aligns with common practices instead of building a custom solution.
Let me know what you guys think. @sandr01d @cjappl @wfxr
I fully agree — switching to Conventional Commits makes sense and using an existing GitHub Action for changelog/release automation is a better approach instead of a custom solution.
I don't have any objections to conventional commits, but I may need some help getting going on them (when/if I contribute in a serious way again). I've been curious about the concept for a while.