Nightly: breakages from bazelrc read order changes #5756

jin · 2018-08-03T14:31:58Z

Build: https://buildkite.com/bazel/bazel-with-downstream-projects-bazel/builds/368

Issue: Change where bazelrcs are read from, and make it easier to control which ones are read.

Gerrit: 16.04, macOS

WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files:
  | /var/lib/buildkite-agent/builds/buildkite-worker-ubuntu1604-java8-ggpl-1/bazel-downstream-projects/gerrit/tools/bazel.rc

rules_jsonnet:

WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files:
  | /Users/buildkite/builds/buildkite-imacpro-2-1/bazel-downstream-projects/rules_jsonnet/tools/bazel.rc

rules_go:

WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files:
  | /Users/buildkite/builds/buildkite-imacpro-10-1/bazel-downstream-projects/rules_go/tools/bazel.rc

rules_typescript:

WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files:
  | /var/lib/buildkite-agent/builds/buildkite-worker-ubuntu1604-java8-mhj7-1/bazel-downstream-projects/rules_typescript/tools/bazel.rc

rules_nodejs:

WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files:
  | /Users/buildkite/builds/buildkite-imacpro-2-1/bazel-downstream-projects/rules_nodejs/tools/bazel.rc

rules_sass:

WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files:
  | /Users/buildkite/builds/buildkite-imacpro-9-1/bazel-downstream-projects/rules_sass/tools/bazel.rc

rules_scala:

WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files:
  | /Users/buildkite/builds/buildkite-imacpro-6-1/bazel-downstream-projects/rules_scala/tools/bazel.rc

BUILD_file_generator

WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files:
  | /Users/buildkite/builds/buildkite-imacpro-2-1/bazel-downstream-projects/BUILD_file_generator/tools/bazel.rc

The text was updated successfully, but these errors were encountered:

cvcal · 2018-08-03T14:52:55Z

These breakages are intentional, and (as I argued in issue #4502) unavoidable. The change at fault is this: ec83598cb6ee4136166bb562a24dc5dfa58921dbT

Copying over the relevant description from the root cause commit:

The old list of bazelrcs was, in order:

%workspace%/tools/bazel.rc (unless --nomaster_bazelrc)

%binary_dir%/bazel.bazelrc (unless --nomaster_bazelrc)

system rc, /etc/bazel.bazelrc or in %ProgramData% for Windows (unless --nomaster_bazelrc)

the first of the following gets called the "user" bazelrc

path passed by flag --bazelrc

%workspace%/.bazelrc

$HOME/.bazelrc

The new list is hopefully a bit more consistent, as:

system rc (unless --nosystem_rc) (same location as before)

workspace, %workspace%/.bazelrc (unless --noworkspace_rc)

user, $HOME/.bazelrc (unless --nohome_rc)

command-line provided, passed as --bazelrc or nothing if the flag is absent.

This means that the following rc's will be ignored from now on:

%workspace%/tools/bazel.rc
%binary_dir%/bazel.bazelrc

The intent is to simplify the list of rc files, and remove the "master" vs "user" grouping that had been confusing. The home and workspace rc are no longer dependent on the --bazelrc flag being present, there are no longer 2 workspace rcs (one gated by --nomaster_bazelrc and one by the presence of an explicit --bazelrc). The binary location was useless to most people, and was legacy from the way that Google's repo is set up, so is excised outright,

cvcal · 2018-08-03T15:08:22Z

This is a breaking change, there's no good way to avoid it, unfortunately.

Why can't we maintain both versions during a deprecation period, allow people to opt-in?
- We can't gate this by startup option. This change affects startup options, including which startup options are accepted (--home_rc, etc) so layering another startup option on top of this is bad.
- We avoid gating things on environment variable - most users lose track of which envvars are set, so this becomes a maintainability problem
- Bazel's client code, in c++, is maintained with a ten-foot stick on this team. We're all much more familiar with the server, so adding complications to the client, to support the dual behavior by some gating method, is undesirable.
- And finally, ending any sort of deprecation period is itself a breaking change - the pain is only postponed. I realize it's nice to control when the tide-over point will be, but with the other concerns, I think it isn't worth it.

Instead, this avoids the duality, but has a very easy workaround, which allows simultaneous support of 2 bazel versions. A warning will let you know if any old rc files are not being read, and you can import them to avoid the confusion:

In your workspace/.bazelrc, add the line import %workspace%/tools/bazel.rc
Similarly, in your system or home rc, whichever is appropriate depending on where you keep the bazel binary, import the %binary_dir%/bazel.bazelrc file.

You can also do this in reverse, migrate the contents of the old files, and have them simply "import" the new ones as needed, but this is a bit more brittle, since you might double-import some files, what with the weird legacy userc behavior. Also, in this order, the warning will continue to be printed, since the old rc files still exist, even if they just contain an import statement - this isn't bad, but log spam annoys certain people.

This way, old Bazels will load the old files, and new ones will get the same flags through the new locations. You can stop doing this once you stop supporting versions of Bazel that expect the old locations.

Note that the flag --[no]master_bazelrc is still accepted - it will be taken into account when creating the warning telling you which old files would have been loaded, but does NOT affect the new files in anyway.

cvcal · 2018-08-03T15:14:30Z

A final piece of advice: If you want additional insight into what Bazel is doing, where it's looking for files, and which files it has found, use the client option --client_debug (bazel --client_debug build): it will give you the full list of potential files (on the log line "Looking for the following rc files:") that it's looking for, and, for each file that it finds and parses, it will also log that.

Another useful option to help debug this sort of thing is --announce_rc, (this is a server option, so it goes after the command, bazel build --announce_rc), and will list all options that are loaded from rc files, along with where they came from. These are output in order that they are parsed by Bazel, which helps find conflicts.

See bazelbuild/bazel#5756 (comment)

See bazelbuild/bazel#5756

davido · 2018-08-03T19:17:35Z

Fix CL for Gerrit: [1].

[1] https://gerrit-review.googlesource.com/c/gerrit/+/191562

* Create .bazelrc See bazelbuild/bazel#5756 (comment) * Update .bazelrc

Since: [1] Bazel changed the list of resource file locations. Adapt to that list and move `%workspace%/tools/bazelrc` to `%workspace%/.bazelrc`. See: [2], [3] for more details. [1] bazelbuild/bazel@ec83598 [2] bazelbuild/bazel#4502 [3] bazelbuild/bazel#5756 Change-Id: Ia13c71bcff7036e2f5541618b28713d9b0d77040

jin · 2018-08-07T19:59:51Z

@cvcal Tensorflow Windows is also broken: https://buildkite.com/bazel/bazel-with-downstream-projects-bazel/builds/372#a57ba36d-90ee-4e31-8f5b-7b91badee678


'build' options: --action_env PYTHON_BIN_PATH=C:/python3/python.exe --action_env PYTHON_LIB_PATH=C:/python3/lib/site-packages --python_path=C:/python3/python.exe --action_env TF_NEED_OPENCL_SYCL=0 --action_env TF_NEED_CUDA=0 --action_env TF_DOWNLOAD_CLANG=0 --define grpc_no_ares=true --strip=always --config monolithic --copt=-w --host_copt=-w --verbose_failures --distinct_host_configuration=false --experimental_shortened_obj_file_path=true --define=override_eigen_strong_inline=true
--
  | ERROR: Config value monolithic is not defined in any .rc file

cvcal · 2018-08-07T20:17:06Z

@jin, yes, that's what #5765 is about

jin · 2018-08-07T20:55:56Z

@cvcal ah, thanks - missed that.

davido · 2018-08-08T09:27:41Z

Mentioned gerrit CL was merged, but only on stable-2.14 branch. We still need to merge that change up to master.

See bazelbuild/bazel#5756 (comment)

Since: [1] Bazel changed the list of resource file locations. Adapt to that list and move `%workspace%/tools/bazelrc` to `%workspace%/.bazelrc`. See: [2], [3] for more details. [1] bazelbuild/bazel@ec83598 [2] bazelbuild/bazel#4502 [3] bazelbuild/bazel#5756 Change-Id: Ia13c71bcff7036e2f5541618b28713d9b0d77040

* Move legacy reproducibility test to new setup (#1585) * Move legacy reproducibility test to new setup Also included: 1. Adds an LLVM toolchain to the WORKSPACE file that can be used to manually test changes against clang on linux. 2. Adds os.PathSeparator to stripped absolute paths to be consistent with stripping being done everywhere else. 3. Adds a test to check the string "bazel-sandbox" in the binary. 4. Uses the cgo binary instead of a pure binary to check for reproducibility in the go_test. 5. Tags the target "collect_digests" as manual. To see how binaries are not reproducible with clang and `-g`, use ``` bazel test --copt=-g --crosstool_top=@llvm_toolchain//:toolchain \ //tests/reproducibility:go_default_test ``` * remove manual tag from reproducibility test * Do not use debug mode for reproducibility test. * Update bazel-toolchain to auto detect OS version * Add a primitive benchmark (#1599) bazel_benchmark checks out rules_go to a temporary directory, creates a temporary workspace, measures the time it takes to build various targets, then appends the times to a .csv file. This will probably be much more sophisticated in the future, but it's good to have something basic now. * go/tools/bazel_benchmark: extract some logic into bash script (#1601) bazel_benchmark.sh is now responsible for cloning rules_go at master into a temp directory. This script can be copied to a bin directory and run with a timer. The rest of the bazel_benchmark.go logic will run at the tip of master. Also: record Bazel version in the output file. * Set Bazel version tested in Travis CI to 0.15.0 (#1604) * Speed up downloading of @go_googleapis by using http_archive. (#1603) The googleapis repository seems to be of such a size that it takes a long time to clone on a link with lower bandwidth. So long, in fact, that it causes timeouts in my case. * Use add_all(), add_joined() instead of deprecated functionality of add() (#1602) * Change crosstool dependency to @bazel_tools//tools/cpp:current_cc_toolchain (#1605) //tools/defaults is a special case which is being removed in Bazel. * Add go_sdk rule and GoSDK provider (#1606) go_sdk is a new rule that gathers information about an SDK and returns a GoSDK provider which will get wired into the toolchain. package_list is a new rule that generates a list of importable packages from the sources in the SDK (previously, we invoked go list, which is slower). * Wire go_sdk and go_toolchain together (#1607) * go_toolchain has a new mandatory attribute, "sdk", which be something that provides GoSDK. * go_host_sdk, go_local_sdk, and go_download_sdk are now macros that wrap the old rules. Each rule declares toolchains in its BUILD.bazel file that work on the host architecture. The macro calls register_toolchains with these. * go_register_toolchains no longer calls register_toolchains, but it will an SDK rule if "go_sdk" isn't defined. This is a step toward allowing multiple SDKs to support multiple execution platforms. * Action inputs are narrowed to use go.sdk.tools and go.stdlib.libs rather than larger sets of files. * stdlib now uses precompiled libraries if the mode is compatible (#1608) * Remove deprecated --batch flag (#1617) * Add go_wrap_sdk rule (#1618) go_wrap_sdk allows you to configure a Go SDK that was downloaded or located with another repository rule. Related #1611 * Optimize args and inputs construction (#1610) * Use add_all() to lazily construct args * add_joined() omits the argument if value is an empty list * Optimize compile * Optimize cover * Simplify tags argument construction * Use any() instead of a dict * Undo depset() usage * Statically link tool binaries (#1615) * A few arguments construction cleanups (#1621) * Update toolchain and provider documentation [skip ci] (#1622) * Document race, msan and other attributes for go_binary, go_test [skip ci] (#1624) * Create .bazelrc (#1626) * Create .bazelrc See bazelbuild/bazel#5756 (comment) * Update .bazelrc * Remove explicit Label() construction (#1627) attr.label() converts strings into labels by itself. * Make go_sdk's package_list optional (#1625) This will eventually be removed when old versions of Gazelle are no longer supported and nothing depends on the file by name. If not provided as an input, go_sdk will generate the file itself. * Update deprecated single_file -> allow_single_file attribute (#1628) Also remove allow_files where it conflicts with allow_single_file (not allowed). Also remove both allow_files and allow_single_file in private attributes where executable is set to True (a file cannot be specified anyway - private attribute). * Document how to avoid proto conflicts [skip ci] (#1631) Fixes #1548 * Set RULES_GO_VERSION to 0.14.0 (#1633) * Propagate mode aspect on "_coverdata" edges (#1632) * Propagate mode aspect on "_coverdata" edges This ensures the coverdata library is built in the same mode as the binary that depends on it. Fixes #1630 * set pure = "on" on test to make CI happy * Update dependencies (#1634) bazel_gazelle to master as of 2018-08-06 com_google_protobuf to v3.6.1 com_github_goog_protobuf to v1.1.1 org_golang_x_net to master as of 2018-08-06 org_golang_google_grpc to v1.14.0 org_golang_google_genproto to master as of 2018-08-06 go_googleapis to master as of 2018-08-06 com_github_kevinburke_go_bindata to v3.11.0 org_golang_x_tools to master as of 2018-08-07 * Announce release 0.14.0 [skip ci] (#1636) Also, fix gazelle example to use prefix directive instead of attribute. * Add CI config to test on RBE. (#1638) * Add CI config to test on RBE. * Disable BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN. This is set by default in the rbe_ubuntu1604 platform, but tests in this repo need this to be disabled. * Skip tests that are not RBE compatible. * Use latest release version of bazel-toolchains repo. (#1639) * Declare org_golang_x_sys in go_rules_dependencies (#1649) The newest version of gRPC depends on @org_golang_x_sys. Since we provide other gRPC dependencies, we should declare this one as well. Fixes #1648 * Document how to override go_rules_dependencies [skip ci] (#1650) Related #1649 * Update minimum version of Bazel for Travis CI to 0.16.0 (#1651) Also, remove logic in .travis.yml for downloading Bazel at HEAD. We're not doing that anymore. * Actions that use go.args may now use param files automatically (#1652) Multiple param files are now supported as well. * Split go.args into go.builder_args and go.tool_args (#1653) Both helpers enable multiline files. Any action using either of these helpers should support them. Other actions may use go.actions.args. go.builder_args adds default arguments that builders should be able to interpret, including -sdk and -tags. go.args is deprecated. * Use -importcfg files for compiling and linking (#1654) The Go toolchain has supported importcfg files since 1.9. These files give the build system finer control over dependencies using importmap and packagefile declarations. Using these files allows us to abandon -I and -L flags, which will help us stay under command line length limits. Fixes #1637 * Update genproto dependencies (#1657) * update org_golang_google_genproto * update go_googleapis * Add test generates long compile/link command lines (#1655) Related #1637 * Remove 'cfg = "data"' from all attributes (#1658) The "data" configuration has been deprecated for a while and has no effect. * Remove gazelle and its deps from go_rules_dependencies (#1659) go_rules_dependencies no longer declares the following repositories: * bazel_gazelle * com_github_bazelbuild_buildtools * com_github_pelletier_go_toml The "gazelle" rule is removed from //go:def.bzl. It has been deprecated for some time, and "gazelle fix" replaces it. * Windows: Use absolute and shortened path for GOROOT environment variable (#1647) * Update tests ahead of Go 1.11 (#1661) A test in the old version of org_golang_x_crypto we were testing fails with Go 1.11. This is fixed in newer versions. * Remove uses of deprecated dictionary concatenation (#1663) This removes the need for --incompatible_disallow_dict_plus * Force absolute paths in builders (#1664) * Update org_golang_x_tools to master as of 2018-08-15 (#1662) * Set RULES_GO_VERSION to 0.15.0 (#1665) * Announce release 0.15.0 [skip ci] (#1666) * one character fix to README boilerplate [skip ci] (#1667) * doc: fix grammatical error (#1671)

See bazelbuild/bazel#5756 PiperOrigin-RevId: 210141555

amlinux · 2018-11-20T08:16:34Z

I was hit by WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files error message, and it was quite unhelpful. I spent a lot of time trying to find where the standard rc files were supposed to be.

Could you please update the message to something referencing the list of standard paths or at least with a link to the doc?

meisterT · 2020-05-12T09:30:39Z

I assume this is no longer relevant.

See bazelbuild/bazel#5756 PiperOrigin-RevId: 210141555

jin assigned cvcal Aug 3, 2018

jin added P1 I'll work on this now. (Assignee required) breakage labels Aug 3, 2018

cvcal added a commit to bazel-contrib/rules_go that referenced this issue Aug 3, 2018

Create .bazelrc

6b8069d

See bazelbuild/bazel#5756 (comment)

schroederc mentioned this issue Aug 3, 2018

Migrate tools/bazelrc to .bazelrc kythe/kythe#2897

Closed

cvcal mentioned this issue Aug 3, 2018

Create .bazelrc bazel-contrib/rules_go#1626

Merged

cvcal added a commit to bazel-contrib/rules_jsonnet that referenced this issue Aug 3, 2018

Create .bazelrc

7ddeb11

See bazelbuild/bazel#5756 (comment)

cvcal mentioned this issue Aug 3, 2018

Create .bazelrc bazel-contrib/rules_jsonnet#65

Merged

cvcal added a commit to cvcal/rules_typescript that referenced this issue Aug 3, 2018

Create .bazelrc

bc87c6f

See bazelbuild/bazel#5756

cvcal mentioned this issue Aug 3, 2018

Create .bazelrc bazelbuild/rules_typescript#246

Closed

cvcal added a commit to cvcal/rules_nodejs that referenced this issue Aug 3, 2018

Create .bazelrc

2dcfbec

See bazelbuild/bazel#5756

cvcal mentioned this issue Aug 3, 2018

Create .bazelrc bazel-contrib/rules_nodejs#267

Closed

cvcal added a commit to bazelbuild/rules_sass that referenced this issue Aug 3, 2018

Create .bazelrc

c58b2b2

See bazelbuild/bazel#5756

cvcal mentioned this issue Aug 3, 2018

Create .bazelrc bazelbuild/rules_sass#42

Closed

cvcal added a commit to bazelbuild/rules_scala that referenced this issue Aug 3, 2018

Create .bazelrc

53a5bee

See bazelbuild/bazel#5756

cvcal mentioned this issue Aug 3, 2018

Create .bazelrc bazelbuild/rules_scala#572

Merged

cvcal added a commit to cvcal/BUILD_file_generator that referenced this issue Aug 3, 2018

Create .bazelrc

df6247d

See bazelbuild/bazel#5756

cvcal mentioned this issue Aug 3, 2018

Create .bazelrc bazelbuild/BUILD_file_generator#38

Open

jayconrod pushed a commit to bazel-contrib/rules_go that referenced this issue Aug 3, 2018

Create .bazelrc (#1626)

3aa1a64

* Create .bazelrc See bazelbuild/bazel#5756 (comment) * Update .bazelrc

jin mentioned this issue Aug 3, 2018

Release - August 2018 - Target RC date: 2018-08-01 - name: 0.17.0 #5059

Closed

perfinion mentioned this issue Aug 4, 2018

Make bazelrc importing a nonexistent file non-fatal #5765

Closed

jin changed the title ~~Nightly: breakages from bazelrc changes~~ Nightly: breakages from bazelrc import order changes Aug 5, 2018

jin changed the title ~~Nightly: breakages from bazelrc import order changes~~ Nightly: breakages from bazelrc read order changes Aug 5, 2018

dslomov pushed a commit to bazel-contrib/rules_jsonnet that referenced this issue Aug 10, 2018

Create .bazelrc (#65)

daf5e73

See bazelbuild/bazel#5756 (comment)

alexeagle pushed a commit to bazelbuild/rules_typescript that referenced this issue Aug 27, 2018

Import tools/bazel.rc in Bazel 0.18's workspace-rc.

088883c

See bazelbuild/bazel#5756 PiperOrigin-RevId: 210141555

meisterT closed this as completed May 12, 2020

alexeagle pushed a commit to alexeagle/rules_nodejs that referenced this issue Oct 17, 2020

Import tools/bazel.rc in Bazel 0.18's workspace-rc.

135a573

See bazelbuild/bazel#5756 PiperOrigin-RevId: 210141555

alexeagle pushed a commit to alexeagle/rules_nodejs that referenced this issue Oct 18, 2020

Import tools/bazel.rc in Bazel 0.18's workspace-rc.

8991303

See bazelbuild/bazel#5756 PiperOrigin-RevId: 210141555

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Nightly: breakages from bazelrc read order changes #5756

Nightly: breakages from bazelrc read order changes #5756

jin commented Aug 3, 2018 •

edited

Loading

cvcal commented Aug 3, 2018 •

edited

Loading

cvcal commented Aug 3, 2018

cvcal commented Aug 3, 2018 •

edited

Loading

davido commented Aug 3, 2018

jin commented Aug 7, 2018

cvcal commented Aug 7, 2018

jin commented Aug 7, 2018

davido commented Aug 8, 2018

amlinux commented Nov 20, 2018

meisterT commented May 12, 2020

Nightly: breakages from bazelrc read order changes #5756

Nightly: breakages from bazelrc read order changes #5756

Comments

jin commented Aug 3, 2018 • edited Loading

cvcal commented Aug 3, 2018 • edited Loading

cvcal commented Aug 3, 2018

cvcal commented Aug 3, 2018 • edited Loading

davido commented Aug 3, 2018

jin commented Aug 7, 2018

cvcal commented Aug 7, 2018

jin commented Aug 7, 2018

davido commented Aug 8, 2018

amlinux commented Nov 20, 2018

meisterT commented May 12, 2020

jin commented Aug 3, 2018 •

edited

Loading

cvcal commented Aug 3, 2018 •

edited

Loading

cvcal commented Aug 3, 2018 •

edited

Loading