Create dependabot.yml#780
Conversation
|
It's not clear to me what this prevents. We are using Docker for testing and creating release binaries, but that's not something we are continue running on a server. So is GitHub Actions -- we are using it only for running tests. What is a possible threat and how useful it is to protect from it? |
bf2c440 to
df9e997
Compare
cc86039 to
25d02bb
Compare
aloisklink
left a comment
There was a problem hiding this comment.
We are using Docker for testing and creating release binaries, but that's not something we are continue running on a server.
I'm pretty sure @dependabot can't yet update Docker dependencies in a GitHub Action workflow, so this change is currently pointless.
So is GitHub Actions -- we are using it only for running tests. What is a possible threat and how useful it is to protect from it?
The main issue is that
Lines 24 to 25 in b78f237
v1 tag of https://github.com/hendrikmuhs/ccache-action
If https://github.com/hendrikmuhs/ccache-action updates this tag to contain a bug, this could break the CI workflows, and it might be difficult to figure out that the bug is caused by hendrikmuhs/ccache-action.
Using a commit hash (like hendrikmuhs/ccache-action@53e53642769c4b03a7881a7283314d1f364134ec) is the best practice when you don't trust the author to break their action. See https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions. You can then use @dependabot to automatically update this hashes to the latest version. But I think this is probably overkill to add to hendrikmuhs/ccache-action (and will just add a lot of noise to the git logs), since in the unlikely event that an hendrikmuhs/ccache-action update breaks something, it will probably just break tests. Every other action is owned by @github or @rui314, so it's also not needed.
But, it might be nice to add @dependabot just so that you don't have to manually update all of the actions/... the next time they have a breaking change. Pretty much all GitHub Actions actions used to run on Node.JS v12, but did a major release when they upgraded to Node.JS v16 (e.g. actions/checkout@v3). And with Node.JS 16 is become end-of-life earlier than normal on 2023-09-11, enabling @dependabot means we won't need to manually bump all of these versions.
| - package-ecosystem: "github-actions" # See documentation for possible values | ||
| directory: "/" # Location of package manifests | ||
| schedule: | ||
| interval: "daily" | ||
|
|
||
| - package-ecosystem: "docker" # See documentation for possible values | ||
| directory: "/" # Location of package manifests | ||
| schedule: | ||
| interval: "daily" | ||
|
|
There was a problem hiding this comment.
This file is invalid YAML, since the indentation is wrong, see:
Error : bad indentation of a sequence entry at line 13, column 4:
- package-ecosystem: "docker" # ...
^
Line : undefined undefined
There was a problem hiding this comment.
Good catch. Indentation fixed.
Fix indentation
|
@aloisklink The GH action will update common/Dockerfile once I update dependabot.yml in my branch. I'm guessing that the Dockerfile in / got moved. |
Point to the right location for the Dockerfile
|
I'm not still convinced that this is necessary. It seems like Dependabot is for web apps or something like that and may not suit well for us. We could still deploy it anyway, but the value of doing it doesn't seem that much. |
|
@rui314 if you take a look at one of the latest actions runs: https://github.com/rui314/mold/actions/runs/11318838986 you'll a pile of warnings. A trivial update of your github actions (as dependabot would do) would resolve these warnings. It's probably worth doing just to keep things tidy. |
|
It is about time to update GitHub actions (#1568). I think it is reasonable to stick to the manual process. I know other mid-sized projects that disabled dependabot because it flooded the project with pull requests to update patchlevel releases in the build pipeline. I am an advocate of using dependabot in Java or JavaScript projects with tons of dependencies. For mold, I side with @rui314 and don't see an advantage. |
|
The flood can be avoided by running monthly instead of daily and by using grouping. This PR currently does neither. |
| - package-ecosystem: "github-actions" # See documentation for possible values | ||
| directory: "/" # Location of package manifests | ||
| schedule: | ||
| interval: "monthly" |
There was a problem hiding this comment.
Consider adding groups to batch updates, otherwise dependabot opens a PR per dependency.
See https://github.com/aya-rs/aya/blob/main/.github/dependabot.yml.
| interval: "monthly" | ||
|
|
||
| - package-ecosystem: "github-actions" # See documentation for possible values | ||
| directory: "/common" # Location of package manifests |
Removed duplicate GitHub Actions dependency configuration and added grouping for actions dependencies.
Add dependabot support to keep GitHub Actions and Docker up to date.
I will submit a separate PR to convert workflows to use commit hashes.