Don't include pulldown-cmark in grouped version updates
#86
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is an attempt to work around the problem seen in GitoxideLabs#85 and discussed in comments there, where even though we prohibit version updates to `pulldown-cmark` already (see `dependendabot.yml`, GitoxideLabs#54, and GitoxideLabs#59), Dependabot has recently begun to attempt them anyway. This may not prevent Dependabot from attempting to update the crate to a version it's not supposed to, but it should cause any such attempts to be done in their own PRs, separate from the main grouped PR where other updates are done.
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this pull request
Nov 24, 2025
Dependabot is working again for cargo dependencies: GitoxideLabs#2245 was due to dependabot/dependabot-core#13345, fixed in dependabot/dependabot-core#13359. However, now we get an analogous problem in here in `gitoxide` with `expectrl` and `imara-diff` to the problem previously encountered in `cargo-smart-release` with `pulldown-cmark`. That was seen in GitoxideLabs/cargo-smart-release#85, where even though it is held back in `dependabot.yml`, Dependabot proposed updates to it in `Cargo.toml`. The analogous problem here can be seen in GitoxideLabs#2268, which includes `expectrl` and `imara-diff`. In GitoxideLabs/cargo-smart-release#86, we worked around the problem in `cargo-smart-release` by explicitly excluding `pulldown-cmark` from grouped updates, so that PRs would be made without it even of Dependabot were to wrongly detect that it should attempt to upgrade it. That was even more effective than anticipated, in that Dependabot also refrained from opening extra non-grouped PRs for it (it heeded the version restrictions again). This attempts an analogous change here in `dependabot.yml` for `gitoxide`, excluding `expectrl` and `imara-diff` from grouped version updates. Hopefully this will at least allow Dependabot grouped version update PRs to be made that don't bump those crates.
This was referenced Nov 24, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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 is an attempt to work around the problem seen in #85 and discussed in comments there, where even though we prohibit version updates to
pulldown-cmarkalready (seedependendabot.yml, #54, and #59), Dependabot has recently begun to attempt them anyway.This may not prevent Dependabot from attempting to update the crate to a version it's not supposed to, but it should cause any such attempts to be done in their own PRs, separate from the main grouped PR where other updates are done.
See #85 (comment) for further context. Assuming this works, the Dependabot PR that will be created automatically once this is merged shall supersede #85 and close it automatically; I am deliberately not closing #85 manually because I want to observe if/when that occurs (and because I think closing it manually could lead to greater confusion when examining it later).
This is a draft until I fully verify that my other attempts to fix this problem in #85 are not working.