chore: add Dependabot config for actions, uv, and docker

[gounthar]

Right now dependency bumps in this repo get noticed by hand, if at all. This adds a .github/dependabot.yml so they show up as PRs instead. Same approach already running in xcp-ng-tests, so nothing exotic here.

Ecosystems, all weekly with a 7-day cooldown:

• github-actions (/): bumps the SHA-pinned actions in the workflows, keeping the pin and the version comment.
• uv: the two uv.lock tools, scripts/git-review-rebase and scripts/kabi.
• docker (/docker/riscv/trixie/image): in practice this only tracks debian:trixie-slim. The baptleduc/xen-riscv64-kernel and the gitlab image come in through a build-arg or a pinned tag, so Dependabot leaves them alone.

One thing I left out on purpose: the driver submodules. They already have update-driver-submodules.yml, which tracks origin/8.3 and re-imports sources. Dependabot's gitsubmodule ecosystem would just fight that, so I kept it clear of them.

I validated this on my fork before opening here: Dependabot picked up the config and opened real uv PRs with the cooldown applied.

Happy to adjust the schedule, the cooldown, or drop an ecosystem if you'd rather start narrower.

[casasnovas]

Thanks for adding this! I can't comment for Baptiste's docker eco-system if he needs version pined for a specific reason, but lgtm for the two python scripts.

There's an issue flagged by by izimor which I'll let you fix.

[gounthar]

Thanks for the review @casasnovas, and good point on the docker side. I left Baptiste's images alone on purpose so I wouldn't step on the build-arg / pinned-tag setup, but happy to revisit if he wants them tracked.

Pushed a fix for the zizmor one (4b30ed2). It was the artipacked finding on update-driver-submodules.yml, and it predates this PR (zizmor was red on main too, not coming from the dependabot config). I didn't take zizmor's auto-fix (persist-credentials: false) because that workflow's "Commit and open PR" step does a git push --force origin and needs the persisted token, and it uploads no artifacts, so the leak path artipacked warns about isn't actually present. Instead I added a small .github/zizmor.yml scoping the artipacked ignore to just that one file, with a comment explaining why. zizmor is green now.

If you'd rather harden it for real (persist-credentials: false plus reworking the push to pass the token explicitly) I'm glad to do that instead, I just didn't want to quietly break the daily importer.

[casasnovas]

Thanks for the review @casasnovas, and good point on the docker side. I left Baptiste's images alone on purpose so I wouldn't step on the build-arg / pinned-tag setup, but happy to revisit if he wants them tracked.

Pushed a fix for the zizmor one (4b30ed2). It was the artipacked finding on update-driver-submodules.yml, and it predates this PR (zizmor was red on main too, not coming from the dependabot config). I didn't take zizmor's auto-fix (persist-credentials: false) because that workflow's "Commit and open PR" step does a git push --force origin and needs the persisted token, and it uploads no artifacts, so the leak path artipacked warns about isn't actually present. Instead I added a small .github/zizmor.yml scoping the artipacked ignore to just that one file, with a comment explaining why. zizmor is green now.

If you'd rather harden it for real (persist-credentials: false plus reworking the push to pass the token explicitly) I'm glad to do that instead, I just didn't want to quietly break the daily importer.

Oh apologies I missed this issue was predating your branch, it's actually my fault and the correct fix is in #35, looks like I inadvertently pushed to main the broken code. There is no need to ignore the warning from zizmor as we can simply make things explicit.

You can either revert your branch to prior state and wait for PR 35 to be merged, or after Baptiste's input I can simply merge your code bypassing the zizmor check since it has nothing to do with your PR.

[gounthar]

No worries, and thanks for digging into it. Makes sense — setting persist-credentials: true explicitly is cleaner than an ignore, and #35 clearly does it properly (plus the xcp-ng-rpms credential config and the git@github.com: submodule-URL fix).

I've reverted my .github/zizmor.yml, so #36 is back to just the dependabot config. zizmor will be red here until #35 lands, since it's the main-branch finding rather than anything in this PR — so whichever is easier for you: merge #35 first and I'll rebase, or merge #36 with the zizmor check bypassed once Baptiste's had a look at the docker eco. Either works.

[baptleduc]

Thanks for adding this! I can't comment for Baptiste's docker eco-system if he needs version pined for a specific reason, but lgtm for the two python scripts.

Sorry for the late reply, I don't think the docker needs a specific version at all.

Igtm as well, thanks for adding this @gounthar !

It looks like you need to add persist-credentials=false required by zizmor.

[gounthar]

Thanks Baptiste, appreciate the look. One wrinkle though: the zizmor finding isn't actually coming from this PR. #36 only adds .github/dependabot.yml, and the red check is the artipacked finding on update-driver-submodules.yml, which is already red on main. @casasnovas traced it last week and the proper fix is in #35. There's a catch with persist-credentials: false specifically: that workflow's "Commit and open PR" step does a git push --force origin and needs the persisted token, so disabling it would break the daily importer (that's casasnovas' read, and it matches what I saw). #35 makes the credentials explicit instead, which seems like the cleaner route. So unless I'm missing something, the simplest path is to land #35 first and I'll rebase this so zizmor goes green, or merge #36 with the zizmor check bypassed since the finding predates it. Whatever's easiest on your side, I'm happy either way.

[baptleduc]

I think the best is to wait #35 to be merged then do a rebase on that to make sure all is green.