What's the easiest way to ignore a specific version/dependency, when you know you can't upgrade to it?

[semkeijsper]

We have multiple NuGet packages we can't upgrade to, for multiple different reasons. We are forced to use .NET 4.8 as we are programming an AutoCAD extension.

So when we decline a PR created by Dependabot, for example xunit.runner.visualstudio@3.0.0, Dependabot will happily create a new PR for xunit.runner.visualstudio@3.0.1. It will abandon the old PR, and reset any knowledge or comments about why the previous PR was rejected.

Would there be a possibility for Dependabot to remember the state of the previous PR of a certain package, and apply it to the one it newly created?

On GitHub you can use comment commands, but I assume this isn't possible on Azure DevOps or is too complex to implement.

Just implementing a carry-over for the PR state would already be a big help.

If there's another way to manage this easily, please let me know.

[rhyskoedijk]

Unfortunately comment commands are not implemented currently; It is tracked by #101.

Recognising abandoned PRs and auto-ignoring them like GitHub does is something I would like to look in to, but isn't implemented yet either.

For now, to ignore packages, use the ignore option in dependabot.yml. e.g.

version: 2
updates:
  - package-ecosystem: "nuget"
    directory: "/"
    ignore:
      # Ignore major version updates for all packages
      - dependency-name: "*"
        update-types: ["version-update:semver-major"]
      # Ignore xunit updates that are not patches
      - dependency-name: "xunit.*"
        update-types: ["version-update:semver-major","version-update:semver-major"]
      # Ignore xunit updates above v3.0.0
      - dependency-name: "xunit.*"
        versions:
          - ">=3.0.0"

[semkeijsper]

Thanks for the answer. Perhaps not recognizing abandoned PRs (as this is automated by Dependabot), but just carrying over the "Rejected" or "Wait for author" status if that has been set. That would be much simpler than implementing the comment commands, but a great quality of life improvement.

Of course being able to include a reason, or notes, as to why a certain package is rejected would be even cooler, but this would be start.

For now I'll look into the ignore functionality in the YAML :)