Dependabot config

[dmcilvaney]

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• [ ] The toolchain has been rebuilt successfully (or no changes were made to it)
• [ ] The toolchain/worker package manifests are up-to-date
• [ ] Any updated packages successfully build (or no packages were changed)
• [ ] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• [ ] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• [ ] All package sources are available
• [ ] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• [ ] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
• [ ] All source files have up-to-date hashes in the *.signatures.json files
• [ ] sudo make go-tidy-all and sudo make go-test-coverage pass
• [ ] Documentation has been updated to match any changes to the build system
• [ ] If you are adding/removing a .spec file that has multiple-versions supported, please add @microsoft/cbl-mariner-multi-package-reviewers team as reviewer (Eg. golang has 2 versions 1.18, 1.21+)
• [ ] Ready to merge

---

Summary

What does the PR accomplish, why was it needed?

Change Log

• Change
• Change
• Change

Does this affect the toolchain?

YES/NO

Associated issues

• #xxxx

Links to CVEs

• https://nvd.nist.gov/vuln/detail/CVE-YYYY-XXXX

Test Methodology

• Pipeline build id: xxxx

[reubeno]

Yes! Dependabot! This is a great idea to look at :)

Some observations from my own experiences with dependabot:

• A package update may sometimes force the consuming component onto a newer version of the language/runtime. I found this with Rust, in which case upgrading the command-line argument parser crate forced my app to a version newer than what Azure Linux supports. This should hopefully be mitigated by GitHub checks that verify the tools still build with the same fixed version of golang. Do we have that in place?

• I've been experimenting with grouping updates, so multiple packages updated at the same time don't spawn a separate PR per package. This seemed particularly useful when using a less frequent update cadence (e.g., weekly or monthly). For reference, here's what I settled on for now for that project.