Github: Enable dependabot for workflow dependencies

[hoffie]

Short description of changes

This PR enables Github's dependabot for Github Action Workflows.
Example PRs:

• CI: Bump actions/cache from 2 to 3 hoffie/jamulus#93
• CI: Bump actions/upload-artifact from 2 to 3 hoffie/jamulus#94
• CI: Bump actions/checkout from 2 to 3 hoffie/jamulus#95
• CI: Bump dev-drprasad/delete-tag-and-release from 0.1.2 to 0.2.0 hoffie/jamulus#96

CHANGELOG: Internal: Enabled automated dependency updates via dependabot and custom automation

Context: Fixes an issue?

Related: #2346

Does this change need documentation? What needs to be documented and how?

No, the PRs are self-documented.

Status of this Pull Request

Ready for review.

What is missing until this pull request can be merged?

• Reviews
• Right after merge whe should check the dependabot page if everything looks good: https://github.com/jamulussoftware/jamulus/settings/security_analysis (especially Dependabot version updates)

Checklist

• I've verified that this Pull Request follows the general code principles
• I tested my code and it does what I want
• My code follows the style guide
• I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• I've filled all the content above

[ann0see]

Thanks. There doesn't seem to be much with it?

[ann0see]

The strange thing is that the CI failed on your PRs...

Edit: you probably stopped it.

[ann0see]

Don't you think this PR should be documented as Internal in the changelog?

[hoffie]

Thanks. There doesn't seem to be much with it?

Well, I've only enabled it for github-actions for now as I don't see any other matches. It seem to be really targeted at certain build environments (npm, go, ...) which perform dependency management. For github-actions, it does what it should. The config is really basic and I think that's fine.

Edit: you probably stopped it.

Yes. I've run lots of CI tests today and had to stop all those autobuild PRs at some point in order to get free slots for further tests. :)

Don't you think this PR should be documented as Internal in the changelog?

Not sure. I think we don't have a guideline regarding that yet. This PR does not change the released artifacts in any way, so I thought I'd skip the CHANGELOG.

[ann0see]

I'd still like to have a changelog entry (maybe for all of these PRs squashed): Internal: Enabled automated dependency updates via dependabot and custom script

[hoffie]

I've added an identical changelog entry for this PR and #2777.
I've opened #2788 for the discussion about CHANGELOG-worthiness.

[ann0see]

I mean, I can’t say much here but thanks!

[ann0see]

After the first PR was opened, I think we should be consistent for all the automated stuff. Either Build: Dependencies: CI: as prefix for all automated PRs.

[hoffie]

My thinking was that dependabot touches CI-only stuff (i.e. workflow dependencies) while the other job touches things which are related to our actual build logic. Therefore, I had chosen different prefixes.

If we want to have a single prefix for all, I'd go with Build:. aqt, Qt, etc. do run in CI, but not solely there, so that would sound wrong.

[ann0see]

I think the real problem is that we haven't agreed on a standard (i.e. when to use CI:, Build:, Autobuild, ...) Probably agreeing gives benefit but also more maintenance/thinking on our side. I'd like to have not too many different prefixes.

[pljones]

Agreed. I don't really care if something is "CI" or "Build" or "Autobuild". If the build breaks, the build breaks. I'm certain (almost) no client or server user cares, either! 😄 So the CHANGELOG entries really can be grouped, so that most people can just skip the lot when they hit them.

If I had to pick, I'd go for "Build" because it covers most ground.

[hoffie]

Change to Build added here: #2803.
I'll manually edit the titles (which are used when no CHANGELOG line is found) of the previous PRs.