Refine Dependabot config to not update rust-toolchain #1364
Conversation
When `dtolnay/rust-toolchain` is a tag, it specifies a particular version of the actual Rust toolchain to use. It is also sometimes used with a branch such as `master` (to then specify the version as an option rather than in the action version) or `stable`, but branches are ineligible for Dependabot version updates and also would not ordinarily require them since they move much more often than tags. Therefore, this tells Dependabot to ignore `dtolnay/rust-toolchain` for the purpose of version updates. As commented, this is done in a way that *should* avoid causing it to be ignored for security updates. Old Rust toolchains may have known vulnerabilities but still be safe to use on CI based on a consideration of the risks (for triggers such as `push` and `pull_request` that run with the same privileges of the user who can cause the triggering event to occur), and I believe the action itself does not get advisories for those versions. But it is possible that at some point in the future a vulnerability might be discovered in the action itself and an advisory produced for it, so having Dependabot be able to show any related alert and, if enabled, produce a security update PR for it automatically is still valuable. Ignoring `dtolnay/rust-toolchain` addresses the problem identified in GitoxideLabs#1362 (review) without requiring any decreased use of actions to install dependencies, modification of how the actions' versions or options are given, or `@dependabot` ignore commands.
|
This probably should not be merged and will probably be closed soon without merging, per c97ee27 and #1362 (comment). |
|
Thanks a lot for the fix! Meanwhile, as already noted in the comment above, the issue was solved differently and it doesn't seem necessary to further protect this action from updates thanks to the way it's used with |
|
Sounds good. Do you know if you are interested in using Dependabot again for the I realize I never mentioned when I brought that up here rather than, for example, in a discussion post. The reason is that I was originally going to delete the old renamed |
|
Thanks for bringing this to my attention, and apologies for not picking up on it earlier. Here is the page you weren't able to see: 
It looks like most of it is enabled. Generally, I really am a fan of updating dependencies myself on an unknown schedule, while keeping everything stable in-between. It is worth noting that In the back of my head, I feel that once |
When
Xindtolnay/rust-toolchain@Xis a tag, it specifies a particular version of the actual Rust toolchain to use. It is also sometimes used with a branch such asmaster(to then specify the version as an option rather than in the action version) orstable, but branches are ineligible for Dependabot version updates and also would not ordinarily require them since they move much more readily than tags. All current uses ofdtolnay/rust-toolchainfall into one of those cases, and therefore it is not necessary for Dependabot version updates to cover it:Therefore, this tells Dependabot to ignore
dtolnay/rust-toolchainfor the purpose of version updates.Dependabot version updates and Dependabot security updates are separate, but some parts of a
dependabot.ymlfile, when present, can affect Dependabot security updates. As commented with details, I have done this in a way that should avoid causing it to be ignored for security updates.pushandpull_requestthat run with the same privileges of the user who can cause the triggering event to occur), and I believe the action itself does not get advisories for those versions.Ignoring
dtolnay/rust-toolchainaddresses the problem identified in #1362 (review) without requiring any decreased use of actions to install dependencies, modification of how the actions' versions or options are given, or@dependabot ignorecommands.There might be a benefit to merging this PR before #1362. Assuming I have managed to write the configuration here correctly, it would then be possible to observe that Dependabot no longer attempts the version update on
dtolnay/rust-toolchain. It might be necessary--and even if not, a good idea--to run@dependabot recreateon that PR after merging this (unless Dependabot closes that PR and makes a new one).Although Dependabot automatically rebases PRs under many circumstances, and furthermore in most cases you should prefer
@dependabot rebaseto@dependabot recreate, the latter is needed to cause Dependabot to discard commits you have manually added. Usually one would not wish to do that, but in this case it would make it possible to observe whether Dependabot avoids making the change that the current manually added commit undoes.Since Dependabot alerts provide information about known security advisories and associated updates without requiring any pull requests to be opened automatically--and offer a button that, when clicked, attempts to create an update PR--I recommend having Dependabot alerts enabled for all dependency types, which will be the case if they are enabled in https://github.com/Byron/gitoxide/settings/security_analysis. (They might already been enabled. I cannot tell if those are enabled or not, since I don't have access to that page on repositories I don't own.)
It might also be worthwhile to allow Dependabot to create security updates, since this will happen immediately, whereas I believe
cargo denyis only running when a push or pull request triggers it. I am not advocating thatcargo denynot be used, only that Dependabot security updates also be considered. These are separate from Dependabot version updates and much lower in volume. It is also recently a stable feature in Dependabot to group multiple security updates in a pull request.Of course, applying only security updates would, over time, lead to a
Cargo.lockwith old versions that might benefit from being newer even for non-security reasons. Updating and pushing it based on the results ofcargo denyupdates everything in it, which could be considered a benefit. Another approach could be to bring back Dependabot version updates forcargodependencies, but group them all together to get just one PR at a time, and set their cadence tomonthly. This would be safe even without usingcargo deny(though that could also be used), so long as Dependabot security updates are enabled, because security alerts and security updates would still occur immediately rather than on the version updates cadence.