Open dmcilvaney opened 1 week ago
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.
Merge Checklist
All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)
*-static
subpackages, etc.) have had theirRelease
tag incremented../cgmanifest.json
,./toolkit/scripts/toolchain/cgmanifest.json
,.github/workflows/cgmanifest.json
)./SPECS/LICENSES-AND-NOTICES/data/licenses.json
,./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md
,./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON
)*.signatures.json
filessudo make go-tidy-all
andsudo make go-test-coverage
passSummary
What does the PR accomplish, why was it needed?
Change Log
Does this affect the toolchain?
YES/NO
Associated issues
xxxx
Links to CVEs
Test Methodology