Closed achilleas-k closed 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.
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.
Ah someone has noticed the same thing:
Thanks! Sorry I missed that. I'll close this one as a dupe.
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
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