bazel-contrib / bazel-contrib/rules_go

Failure fetching go_repository using "go mod download" when repo vendors deps

Open
#2,872 2 comments 1 reaction 0 assignees View on GitHub
Dominant language
Go
Stars
1.5k
Forks
760
Avg merge
1d 11h
Merged PRs (30d)
12

Description

### What version of rules_go are you using?

[`rules_go-v0.24.2`](https://github.com/bazelbuild/rules_docker/blob/3fc4b0a177dd36ee0d6f0c8b943fd5d97597ef10/repositories/repositories.bzl#L111-L119)

### What version of gazelle are you using?

[`bazel-gazelle-v0.21.1`](https://github.com/bazelbuild/rules_docker/blob/3fc4b0a177dd36ee0d6f0c8b943fd5d97597ef10/repositories/repositories.bzl#L178-L183)

### What version of Bazel are you using?

```
$ bazel version
Build label: 4.0.0-homebrew
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Sat Jan 23 02:07:47 2021 (1611367667)
Build timestamp: 1611367667
Build timestamp as int: 1611367667
```

This failure also reproduces in CI checks for the PR in question.

### Does this issue reproduce with the latest releases of all the above?

I don't know.

### What operating system and processor architecture are you using?

macOS Big Sur 11.2.3, x86_64

### Any other potentially useful information about your toolchain?

Nope

### What did you do?

In https://github.com/bazelbuild/rules_docker/pull/1831/, I'm trying to update `rules_docker`'s dependencies on some Go packages to fetch them by `version`+`sum` (using `go mod download`) instead of using GitHub's dynamically generated source archives. Relying on GitHub's source archives has produced undesirable nondeterministic behavior in the past (https://github.com/bazelbuild/rules_docker/pull/1829, https://github.com/kubernetes/kubernetes/issues/99376).

The change doesn't modify the version being fetched, just _how_ they're fetched.

In the case of the `go-containerregistry` dependency, it was previously fetched by `commit`, which worked fine. Switching it to the `go mod download` alternative causes the build to fail with:

```
ERROR: /private/var/tmp/_bazel_jasonhall/fcc352ac3576a83d75941dc59496ceb7/external/com_github_google_go_containerregistry/pkg/authn/BUILD.bazel:3:11: no such package '@com_github_docker_cli//cli/config/types': The repository '@com_github_docker_cli' could not be resolved and referenced by '@com_github_google_go_containerregistry//pkg/authn:go_default_library'
```

No other dependencies cause this failure, only go-containerregistry. I believe the reason for this is that go-containerregistry is the only dependency of those that vendors its dependencies.

### What did you expect to see?

I expected all dependencies to be successfully fetched and built.

### What did you see instead?

See error message above.

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the rules_docker pull request 1831 setup with the go-containerregistry dependency and the reported Bazel versions. Compare the commit-based fetch with the go mod download path, focusing on vendored dependencies and the unresolved @com_github_docker_cli repository. Done means all dependencies resolve and the affected build succeeds.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
build-system
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.