-
Notifications
You must be signed in to change notification settings - Fork 386
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GOTOOLCHAIN local env parameter breaks the fetch of external go repositories #1858
Comments
ghost
mentioned this issue
Aug 7, 2024
This was referenced Oct 20, 2024
fmeum
pushed a commit
to bazel-contrib/rules_go
that referenced
this issue
Oct 21, 2024
- **Update to gazelle 0.39.1** - **Wrap generate_imported_dylib.sh in genrules** **What type of PR is this?** Bug fix **What does this PR do? Why is it needed?** This PR fixes 3 issues which caused an invocation of `bazel test //...` in a clean checkout of the repository to fail depending on potential contributor's development environment. 1. Contributors needed to know to run `generate_imported_dylib.sh` 2. Contributors needed to have $JAVA_HOME set 3. Contributors needed NOT to have `go env GOTOOLCHAIN` set For 1, this PR wraps the `generate_imported_dylib.sh` in genrules so that the build will just automatically create the dynamic libraries appropriate for the platform. For 2, the PR adds a `--java_runtime_version=remotejdk_21` argument to the one test in `lcov_coverage_test.go` that needs to be able to build a Java rule. For 3, the PR upgrades `gazellle` to version 0.39.1 and updates the excludes lists in the `popular_repos.py` file to handle the latest versions of those popular repos. This upgrade addresses the problem because bazel-contrib/bazel-gazelle#1858 is fixed in that version of gazelle. BONUS: Also, there were a few TODOs left in the `WORKSPACE` and `.bazelrc` files which were addressed by upgrading to the latest `gazelle` version. So, this PR cleans those up at the same time. **Which issues(s) does this PR fix?** Fixes #4149 **Other notes for review** I have tested this on the following two machines: macos (M3 arm64) linux (amd64) In both cases, I can clone the repository into an fresh directory hop onto the `build-fixes` branch and run: ``` ❯ bazel test -j 8 //... ``` And, it actually has all 452 tests passing within 30 minutes or so. On both machines, `go env GOTOOLCHAIN` is `go1.23.2` and `$JAVA_HOME` is not set on either machine.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
None yet
0 participants
What version of gazelle are you using?
0.38.0
What version of rules_go are you using?
0.49.0
What version of Bazel are you using?
7.2.1
Does this issue reproduce with the latest releases of all the above?
Yes
What operating system and processor architecture are you using?
All
What did you do?
With an empty bazel workspace + the following
MODULE.bazel
:$ go env -w GOTOOLCHAIN=go1.22.5 # Use a Go version different of the Go version defined in `go_sdk` $ bazel fetch --repo @@gazelle~~go_deps~org_golang_x_sync
What did you expect to see?
What did you see instead?
The text was updated successfully, but these errors were encountered: