Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This project uses the
upload-artifact
anddownload-artifact
actions which, when updated with breaking changes, must be advanced together. But currently Dependabot attempts to update them separately. Each of the pull requests #184 and #186 were created separately, so they both fail for the checks that usecross
(since thecross
binary is cached as an artifact). If they were both merged in the hope that, together, they would work, then that would run the risk of missing some other problem, and it would also create a situation where, after one has been merged and the other has not, CI would be broken.This modifies
dependabot.yml
so that Dependabot version updates are grouped. This should always solve that kind of problem, and do so without sacrificing automation. I have confirmed that it solves the current case of it, by enabling Dependabot version updates in my fork, observing that EliahKagan#1 and EliahKagan#3 fail the CI checks that use those actions, then making the change proposed here and observing that all checks pass in EliahKagan#4.Furthermore, the current maximum of 3 Dependabot version update PRs suggests a preference for a small volume of them. Grouping them will almost always make it so there is at most one such PR, which is in line with that preference, while still allowing all available updates to be offered no matter how many or few of them there are. (It is only "almost always" due to conditions involving when a new PR causes an old PR to become obsolete, which happens only after the new PR is created, as well as situations involving Dependabot security updates.)
If this PR is merged, then Dependabot will create a grouped version update PR including the changes in #184 and #186 (and possibly others, if there are other versions that can be bumped). It should then immediately thereafter automatically close those two PRs (even if the new PR has not been merged).