dependabot / dependabot-core

🤖 Dependabot's core logic for creating update PRs.
https://docs.github.com/en/code-security/dependabot
MIT License
4.67k stars 1.01k forks source link

Gomod dependency gets downgraded after manual update #8949

Closed achilleas-k closed 8 months ago

achilleas-k commented 8 months ago

Is there an existing issue for this?

Package ecosystem

gomod

Package manager version

go 1.19

Language version

go 1.19

Manifest location and content before the Dependabot update

No response

dependabot.yml content

https://github.com/osbuild/images/blob/main/.github/dependabot.yml

version: 2
updates:

  # Maintain dependencies for GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
      time: "04:00"
    open-pull-requests-limit: 5
    rebase-strategy: "disabled"

  # Maintain dependencies for Go
  - package-ecosystem: "gomod"
    directory: "/"
    schedule:
      interval: "daily"
      time: "04:00"
    groups:
      go-deps:
        patterns:
          - "*"  # group all dependency updates into one PR
    open-pull-requests-limit: 1
    rebase-strategy: "auto"

Updated dependency

github.com/containers/image/v5

What you expected to see, versus what you actually saw

What I expect: dependabot should not be downgrading a dependency What happens: dependabot PRs downgrade a dependency every time it runs

Description

About a week ago, a dependabot PR pulled in updates that were incompatible with a specific dependency. I manually updated the dependency from v5.22.1 to v5.29.1 and included it in the PR.

Since then, every dependabot PR reverts the change to v5.22.1 of github.com/containers/image/v5, but fails because of the incompatibility.

Most recent example: https://github.com/osbuild/images/pull/416 (see: https://github.com/osbuild/images/pull/416/files#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6L17) See also:

Native package manager behavior

No response

Images of the diff or a link to the PR, issue, or logs

Smallest manifest that reproduces the issue

No response

jakecoffman commented 8 months ago

Dependabot invokes the Go CLI to do updates, I can reproduce this outside of Dependabot like so:

$ git clone --depth=1 https://github.com/osbuild/images.git
Cloning into 'images'...
remote: Enumerating objects: 8250, done.
remote: Counting objects: 100% (8250/8250), done.
remote: Compressing objects: 100% (5604/5604), done.
remote: Total 8250 (delta 2400), reused 6776 (delta 2140), pack-reused 0
Receiving objects: 100% (8250/8250), 18.23 MiB | 8.98 MiB/s, done.
Resolving deltas: 100% (2400/2400), done.
Updating files: 100% (7194/7194), done.
$ cd images
$ go get github.com/opencontainers/image-spec@v1.1.0-rc.6
go: downgraded github.com/Microsoft/hcsshim v0.12.0-rc.1 => v0.10.0-rc.3
go: downgraded github.com/containerd/containerd v1.7.0 => v1.6.19
go: downgraded github.com/containers/image/v5 v5.29.1 => v5.22.1
go: downgraded github.com/containers/storage v1.51.0 => v1.48.1
go: downgraded github.com/google/go-containerregistry v0.16.1 => v0.11.0
go: downgraded github.com/opencontainers/image-spec v1.1.0-rc5 => v1.1.0-rc.6
go: downgraded github.com/sigstore/fulcio v1.4.3 => v1.0.0
go: downgraded github.com/sigstore/rekor v1.2.2 => v1.0.1
go: downgraded github.com/sigstore/sigstore v1.7.5 => v1.4.4
go: downgraded github.com/sylabs/sif/v2 v2.15.0 => v2.8.3
$ grep image\/v5 go.mod 
    github.com/containers/image/v5 v5.22.1

It looks like there are some competing dependencies:

$ go mod graph | grep github.com/containers/image/v5
github.com/osbuild/images github.com/containers/image/v5@v5.29.1
github.com/containers/common@v0.49.3 github.com/containers/image/v5@v5.22.0

Both of those depend on the same dependency, so I was curious what would happen if we tell Go to update both of them at the same time:

$ go get github.com/containers/common@v0.57.3 github.com/opencontainers/image-spec@v1.1.0-rc.6
go: github.com/containers/common@v0.57.3 requires github.com/opencontainers/image-spec@v1.1.0-rc5, not github.com/opencontainers/image-spec@v1.1.0-rc.6

That seems to be the root cause of the issue. In grouped updates, Dependabot runs go get on each dependency individually so it doesn't surface this since the Go tooling found a way to make it work via downgrades.

jakecoffman commented 8 months ago

Ah someone has noticed the same thing:

It seems the pre-release format has changed and it might be messing up the update. You can try ignoring v1.1.0-rc.6 of github.com/opencontainers/image-spec since it sorts larger than rc6 and then Dependabot will choose it to give to the go get command. That should avoid the downgrades.

achilleas-k commented 8 months ago

Ah someone has noticed the same thing:

Thanks! Sorry I missed that. I'll close this one as a dupe.

achilleas-k commented 8 months ago

Duplicate of https://github.com/dependabot/dependabot-core/issues/8847