Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dependabot: Ignore patch updates of Rust crates (Cargo) #310

Conversation

primeos-work
Copy link
Member

We currently use the following strategy to avoid too many dependabot PRs (i.e., to reduce the noise and work required to merge them): We set the update interval to monthly and manually run cargo update just before the scheduled dependabot run to commit all compatible updates at once.

We only need dependabot to update Cargo.toml and to open PRs for security updates right away.

We don't lock any dependencies to specific patch version so we can instruct dependabot to ignore all patch updates as that should never require updates to Cargo.toml. This setting also shouldn't affect/prevent security updates (the documentation isn't that clear on this 0 but at least we'd notice as it certainly shouldn't affect the dependabot (security) alerts) and we still get the patch updates via our cargo update batches.
We cannot ignore minor updates as well due to 0.y.z releases (we lock those to the minor version in Cargo.toml as patch releases usually don't change the API even though SemVer theoretically allows this).

PS: We're using the default dependabot configuration that only updates direct dependencies (except for security updates) so we need to perform major/minor/patch updates of indirect dependencies manually through cargo update anyway.

We currently use the following strategy to avoid too many dependabot PRs
(i.e., to reduce the noise and work required to merge them): We set the
update interval to monthly and manually run `cargo update` just before
the scheduled dependabot run to commit all compatible updates at once.

We only need dependabot to update `Cargo.toml` and to open PRs for
security updates right away.

We don't lock any dependencies to specific patch version so we can
instruct dependabot to ignore all patch updates as that should never
require updates to `Cargo.toml`. This setting also shouldn't
affect/prevent security updates (the documentation isn't that clear on
this [0] but at least we'd notice as it certainly shouldn't affect the
dependabot (security) alerts) and we still get the patch updates via our
`cargo update` batches.
We cannot ignore minor updates as well due to `0.y.z` releases (we lock
those to the minor version in `Cargo.toml` as patch releases usually
don't change the API even though SemVer theoretically allows this).

PS: We're using the default dependabot configuration that only updates
direct dependencies (except for security updates) so we need to perform
major/minor/patch updates of indirect dependencies manually through
`cargo update` anyway.

[0]: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#specifying-dependencies-and-versions-to-ignore

Signed-off-by: Michael Weiss <michael.weiss@atos.net>
@primeos-work
Copy link
Member Author

I also recently had to close a few dependabot PRs as I forgot to run cargo update in advance: https://github.com/science-computing/butido/pulls?q=is%3Apr+is%3Aclosed+label%3Adependencies

I could've theoretically merged them instead but that can also create Git merge conflicts, especially if they bump many indirect dependencies (possibly even to different versions). Using cargo update is less work (since we need it for the indirect dependencies anyway) and IMO also cleaner (makes the dependabot PRs smaller / easier to review and more "meaningful").

@primeos-work primeos-work added this pull request to the merge queue Nov 6, 2023
Merged via the queue into science-computing:master with commit 3207ebe Nov 6, 2023
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant