Skip to content
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

Bazel 0.21.0 flipped --incompatible_strict_action_env to true and broke itself #7026

Open
philwo opened this Issue Jan 2, 2019 · 43 comments

Comments

@philwo
Copy link
Member

philwo commented Jan 2, 2019

Description of the problem / feature request:

Bazel 0.21.0 flipped --incompatible_strict_action_env to true via #6648, which broke CI on macOS and Windows CI. On macOS we can no longer find "md5" (which is in /sbin) and on Windows we can no longer find Python, PowerShell and other tools.

We didn't discover these breakages during testing, because apparently we don't actually test Bazel itself in the "Bazel@HEAD + Downstream Projects".

We'll revert this via a flag in the CI config files, but flag owners should work on fixing our tests (and taking user feedback into account whether this new behavior is actually working well for others) so that we can eventually remove the config entry again.

Relevant logs:

@laszlocsomor

This comment has been minimized.

Copy link
Contributor

laszlocsomor commented Jan 2, 2019

Philipp, thanks for finding, filing, and working around this bug.

We (@philwo , @hlopko , and myself) argued about this flag today and realized that, while sh_* rules should probably not run python directly (why would a shell script need to do that?), they should be able to run their py_binary data-dependencies, which rightfully expect to have python / python.exe on the PATH.

It's unclear to me what should Bazel do. It seems that PATH's whole purpose is to contain the locations of these common tools, in which case PATH should be exempt from the "strict" env and be available to the action. On the other hand, PATH is inherently machine-specific and as such it poisons remote caches.

Another important observation @philwo made is that the "strict" action env is just as non-hermetic as the non-strict one; we just replace the clientenv's PATH with a hardcoded PATH string, but whatever is in those directories is out of our control (and not tracked by Bazel). And on one machine they might have python (and point to python2) but on another they might have no python at all or have python pointing to python3.

@benjaminp

This comment has been minimized.

Copy link
Collaborator

benjaminp commented Jan 2, 2019

One option would be to make PATH work more like TMPDIR, where it's not part of the action key and injected by the spawn runner at the last moment. That would be a step towards fixing #6392, too.

meteorcloudy added a commit to bazelbuild/continuous-integration that referenced this issue Jan 2, 2019

@meteorcloudy

This comment has been minimized.

Copy link
Member

meteorcloudy commented Jan 2, 2019

To prevent this from happening again, I filed bazelbuild/continuous-integration#434

@brandjon

This comment has been minimized.

Copy link
Member

brandjon commented Jan 4, 2019

they should be able to run their py_binary data-dependencies, which rightfully expect to have python / python.exe on the PATH. [...] On the other hand, PATH is inherently machine-specific and as such it poisons remote caches.

I can't speak for PATH in general, but from the point of view of the Python interpreter: The long-term solution is to define the interpreter as a toolchain rule, where a particular toolchain target is appropriate for a specific system / path installation. The toolchain target for the current host system could be generated by a repository rule.

Currently py_runtime is the closest thing we have to a toolchain. The Python stub script only runs the python on PATH if no py_runtime was specified via --python_top.

@laszlocsomor

This comment has been minimized.

Copy link
Contributor

laszlocsomor commented Jan 7, 2019

@brandjon : Can you explain how executing a py_binary-generated target would work if the python interpreter is a toolchain? As I see it, running bazel-bin/foo/py/bin (which is currently a symlink to the stub python script, whose shebang line is #!/usr/bin/env python) requires an interpreter on the PATH.

@laszlocsomor

This comment has been minimized.

Copy link
Contributor

laszlocsomor commented Jan 7, 2019

And this is only the Linux/macOS stub script. On Windows we have another stub that is a C++ program (called the "launcher"). @meteorcloudy could correct me on this, but IIRC the local python interpreter's path is embedded in the launcher.

@meteorcloudy

This comment has been minimized.

Copy link
Member

meteorcloudy commented Jan 7, 2019

@laszlocsomor The native launcher also only uses python on PATH if no py_runtime was specified, basically it always uses the same python binary as the python stub template, see

return createWindowsExeLauncher(ruleContext, pythonBinary, executable, true);

That said, the python binary (including the native launcher for python) won't be a problem if python path is explicitly specified even with --incompatible_strict_action_env

@ulfjack ulfjack removed their assignment Jan 7, 2019

@ulfjack

This comment has been minimized.

Copy link
Contributor

ulfjack commented Jan 7, 2019

I think we need to change the default PATH on macos and Windows. It might be worthwhile to roll back the flag flip, except it may be too late now?

@laszlocsomor

This comment has been minimized.

Copy link
Contributor

laszlocsomor commented Jan 7, 2019

@meteorcloudy : Thanks, that's comforting to know.
@ulfjack : I agree that it's probably too late to roll back the flag flip commit now. What do you think the default PATH should contain on macOS and Windows?

@filipesilva

This comment has been minimized.

Copy link

filipesilva commented Jan 7, 2019

Regarding Windows:

@ulfjack

This comment has been minimized.

Copy link
Contributor

ulfjack commented Jan 7, 2019

I don't have a mac available right now, but I take it /sbin is on the PATH by default, so we should add it to the default path in Bazel as well.

It's
/Users/[user]/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:
according to https://www.reddit.com/r/MacOS/comments/5zabo3/question_what_is_the_default_path_for_macos/, although we should leave out the users home bin directory for hermeticity.

@ulfjack

This comment has been minimized.

Copy link
Contributor

ulfjack commented Jan 7, 2019

For a specific proposal, I'd say we should at least set it to /usr/bin:/bin:/usr/sbin:/sbin on macOS.

@meteorcloudy

This comment has been minimized.

Copy link
Member

meteorcloudy commented Jan 7, 2019

I assume the strict PATH env should contain the most common native tools available on that platform. For Windows, I think they should be:

  • C:\Windows and C:\Windows\System32, for common Windows cmd commands, eg. findstr.exe, whoami.exe, where.exe etc.
  • C:\Windows\System32\WindowsPowerShell\v1.0, for powershell.exe. @philwo pointed out different powershell versions are all installed in this same path, even if v1.0 is in the path.
  • C:\tools\msys64\usr\bin and C:\tools\msys64\bin, for bash bin tools. This will change if users specify a different bash executable by --shell_executable or shell toolchain.

But there are two issues to be considered on Windows:

  1. System root could change. Although the most common system root is C:\Windows, users could have different system root. If that's not C:\Windows, the default PATH env is wrong. One possible solution is to replace C:\Windows with %SYSTEMROOT%. We always set %SYSTEMROOT% for every action on Windows and it's a special env var set before launching the process, which won't affect any action cache. See
    String[] systemEnvironmentVars = {"SYSTEMROOT", "SYSTEMDRIVE"};
  2. File paths are case insensitive on Windows. Currently, if you change PATH from C:\foo\bar to C:\Foo\bar, the action will be re-executed, I think we should fix this.
@ulfjack

This comment has been minimized.

Copy link
Contributor

ulfjack commented Jan 8, 2019

We need to achieve three things here:

  1. Have a default that's generally usable for local builds
  2. The default must work with remote execution (e.g., no local usernames, machine-specific directories, etc.); this is to avoid cache thrashing / cross-user cache misses by default
  3. Be easy to override as needed (with the caveat that different settings across users can cause cache misses / thrashing)

I think the images that will be built / are already being built for remote execution will largely put binaries in the locations matching the default PATH.

(I don't think I'm saying anything new, just trying to clarify the situation. Using %SYSTEMROOT% in PATH should be fine; however, we do need to figure out how to handle %SYSTEMROOT% with remote execution to prevent remote cache thrashing.)

@laszlocsomor

This comment has been minimized.

Copy link
Contributor

laszlocsomor commented Jan 8, 2019

Re @meteorcloudy :
I agree those paths (powershell, system32, msys2 bin and usr/bin) should be on the strict PATH, and nothing more.
Challenge 1 seems to be workaround-able.
I don't see why challenge 2 is a problem in the strict env case (or did you mean this for non-strict env builds?) What am I missing?

Also, it's not clear to me anymore who's waiting on whose input and who are decision makers on this bug. How can we move forward?

I'm happy to volunteer to add an incompatible flag enabling the strict PATH that @meteorcloudy proposed.

@edbaunton

This comment has been minimized.

Copy link
Contributor

edbaunton commented Jan 22, 2019

This is being further discussed on the mailing list here and here.

aehlig added a commit that referenced this issue Jan 23, 2019

undo flag flip of --incompatible_strict_action_env
it breaks local execution users. we'll need some more time to figure out a better solution that works for both remote and local execution.

RELNOTES: The default value for --incompatible_strict_action_env has been flipped to 'false' again, as we discovered breakages for local execution users. We'll need some more time to figure out the best way to make this work for local and remote execution. Follow #7026 for more details.
PiperOrigin-RevId: 229917346

aehlig added a commit that referenced this issue Jan 23, 2019

undo flag flip of --incompatible_strict_action_env
it breaks local execution users. we'll need some more time to figure out a better solution that works for both remote and local execution.

RELNOTES: The default value for --incompatible_strict_action_env has been flipped to 'false' again, as we discovered breakages for local execution users. We'll need some more time to figure out the best way to make this work for local and remote execution. Follow #7026 for more details.
PiperOrigin-RevId: 229917346

bazel-io pushed a commit that referenced this issue Jan 28, 2019

Release 0.22.0 (2019-01-28)
Baseline: deb028e

Cherry picks:

   + a3a5975:
     Fix a race condition in remote cache
   + b8d0e1b:
     Use a new GitHub token and KMS key for the release process.
   + 3759e38:
     remote: fix unexpected IO error (not a directory)
   + 4473bb1:
     Fix a race condition in Bazel's Windows process management.
   + 9137fb9:
     undo flag flip of --incompatible_strict_action_env
   + 12ab12e:
     Revert "Enabling Bazel to generate input symlinks as defined by
     RE AP?
   + 6345c74:
     Automated rollback of commit
     30536ba.

New features:

  - Add inputs filtering for aquery
  - https://docs.bazel.build now supports versioned
    documentation. Use the selector at the top of the navigation bar
    to
    switch between documentation for different Bazel releases.
  - build_tar.py in tools/build_defs/pkg now supports a json manifest
    that can be used to add paths that have symbols that can't be
    specified via the command line

Important changes:

  - Added `--incompatible_dont_emit_static_libgcc`
    (#6825)
    Added `--incompatible_linkopts_in_user_link_flags`
    (#6826)
  - mobile-install now works with aapt2. Try it out with `bazel
    mobile-install --android_aapt=aapt2 //my:target`
  - Fixed a mobile-install v1 bug when deploying to Android 9 Pie
    devices. #6814
  - Add a new option --xbinary_fdo to pass xbinary profile.
  - --runs_per_test: place in TESTING documentation category.
  - Adds a clarifying message to test case summary output when all
    test cases pass but the target fails.
  - Fixed mobile-install v1 error when installing an app with native
    libraries onto an Android 9 (Pie) device. See
    bazelbuild/examples#77
  - Fixed issue where error messages from Android manifest merging
    actions were not propagated fully.
  - Add outputs and mnemonic filtering to aquery
  - New incompatible change flag for defaulting to aapt2 in Android
    builds: `--incompatible_use_aapt2_by_default`. To build with
    aapt2 today, pass the flag
    `--incompatible_use_aapt2_by_default=true` or
    `--android_aapt=aapt2`, or set the `aapt_version`  to `aapt2` on
    your `android_binary` or `android_local_test` target.
  - set projectId in all PublishBuildToolEventStreamRequest
  - Flip flag --incompatible_string_is_not_iterable
    (#5830)
  - cc_toolchain.(static|dynamic)_runtime_libs attributes are now
    optional
  - Added --incompatible_disable_runtimes_filegroups
    (#6942).
  - objc_bundle has been removed. Please migrate to rules_apple's
    [apple_bundle_import](https://github.com/bazelbuild/rules_apple/bl
    ob/master/doc/rules-resources.md#apple_bundle_import).
  - The apple_stub_binary rule has been deleted.
  - Incompatible flag `--incompatible_dont_emit_static_libgcc` has
    been flipped (#6825)
  - Incompatible flag `--incompatible_linkopts_in_user_link_flags`
    has been flipped (#6826)
  - Open source aquery & cquery query2 tests
  - Fixed a mobile-install bug where `arm64-v8a` libraries were not
    deployed correctly on `arm64` devices. This was done by enabling
    incremental native lib deployment by default. A previously
    undocumented `--android_incremental_native_libs` flag is removed,
    and is now the regular behavior. See
    #2239
  - Incompatible flag `--incompatible_linkopts_in_user_link_flags`
    has been flipped (#6826)
  - Incompatible flag `--incompatible_dont_emit_static_libgcc` has
    been flipped (#6825)
  - Added --incompatible_disable_legacy_crosstool_fields. See the
    migration notes at
    #6861.
  - In the Query HowTo, recommend ":*" instead of ":all". "all" might
    be the name of a target.
  - The default value for --incompatible_strict_action_env has been
    flipped to 'false' again, as we discovered breakages for local
    execution users. We'll need some more time to figure out the best
    way to make this work for local and remote execution. Follow
    #7026 for more details.

This release contains contributions from many people at Google, as well as Benjamin Peterson, Dave Lee, George Gensure, Gert van Dijk, Gustavo Storti Salibi, Keith Smiley, Loo Rong Jie, Lukasz Tekieli, Mikhail Mazurskiy, Thi, Travis Cline, Vladimir Chebotarev, Yannic.

weixiao-huang added a commit to weixiao-huang/bazel that referenced this issue Jan 31, 2019

undo flag flip of --incompatible_strict_action_env
it breaks local execution users. we'll need some more time to figure out a better solution that works for both remote and local execution.

RELNOTES: The default value for --incompatible_strict_action_env has been flipped to 'false' again, as we discovered breakages for local execution users. We'll need some more time to figure out the best way to make this work for local and remote execution. Follow bazelbuild#7026 for more details.
PiperOrigin-RevId: 229917346

weixiao-huang added a commit to weixiao-huang/bazel that referenced this issue Jan 31, 2019

Release 0.22.0 (2019-01-28)
Baseline: deb028e

Cherry picks:

   + a3a5975:
     Fix a race condition in remote cache
   + b8d0e1b:
     Use a new GitHub token and KMS key for the release process.
   + 3759e38:
     remote: fix unexpected IO error (not a directory)
   + 4473bb1:
     Fix a race condition in Bazel's Windows process management.
   + 9137fb9:
     undo flag flip of --incompatible_strict_action_env
   + 12ab12e:
     Revert "Enabling Bazel to generate input symlinks as defined by
     RE AP?
   + 6345c74:
     Automated rollback of commit
     30536ba.

New features:

  - Add inputs filtering for aquery
  - https://docs.bazel.build now supports versioned
    documentation. Use the selector at the top of the navigation bar
    to
    switch between documentation for different Bazel releases.
  - build_tar.py in tools/build_defs/pkg now supports a json manifest
    that can be used to add paths that have symbols that can't be
    specified via the command line

Important changes:

  - Added `--incompatible_dont_emit_static_libgcc`
    (bazelbuild#6825)
    Added `--incompatible_linkopts_in_user_link_flags`
    (bazelbuild#6826)
  - mobile-install now works with aapt2. Try it out with `bazel
    mobile-install --android_aapt=aapt2 //my:target`
  - Fixed a mobile-install v1 bug when deploying to Android 9 Pie
    devices. bazelbuild#6814
  - Add a new option --xbinary_fdo to pass xbinary profile.
  - --runs_per_test: place in TESTING documentation category.
  - Adds a clarifying message to test case summary output when all
    test cases pass but the target fails.
  - Fixed mobile-install v1 error when installing an app with native
    libraries onto an Android 9 (Pie) device. See
    bazelbuild/examples#77
  - Fixed issue where error messages from Android manifest merging
    actions were not propagated fully.
  - Add outputs and mnemonic filtering to aquery
  - New incompatible change flag for defaulting to aapt2 in Android
    builds: `--incompatible_use_aapt2_by_default`. To build with
    aapt2 today, pass the flag
    `--incompatible_use_aapt2_by_default=true` or
    `--android_aapt=aapt2`, or set the `aapt_version`  to `aapt2` on
    your `android_binary` or `android_local_test` target.
  - set projectId in all PublishBuildToolEventStreamRequest
  - Flip flag --incompatible_string_is_not_iterable
    (bazelbuild#5830)
  - cc_toolchain.(static|dynamic)_runtime_libs attributes are now
    optional
  - Added --incompatible_disable_runtimes_filegroups
    (bazelbuild#6942).
  - objc_bundle has been removed. Please migrate to rules_apple's
    [apple_bundle_import](https://github.com/bazelbuild/rules_apple/bl
    ob/master/doc/rules-resources.md#apple_bundle_import).
  - The apple_stub_binary rule has been deleted.
  - Incompatible flag `--incompatible_dont_emit_static_libgcc` has
    been flipped (bazelbuild#6825)
  - Incompatible flag `--incompatible_linkopts_in_user_link_flags`
    has been flipped (bazelbuild#6826)
  - Open source aquery & cquery query2 tests
  - Fixed a mobile-install bug where `arm64-v8a` libraries were not
    deployed correctly on `arm64` devices. This was done by enabling
    incremental native lib deployment by default. A previously
    undocumented `--android_incremental_native_libs` flag is removed,
    and is now the regular behavior. See
    bazelbuild#2239
  - Incompatible flag `--incompatible_linkopts_in_user_link_flags`
    has been flipped (bazelbuild#6826)
  - Incompatible flag `--incompatible_dont_emit_static_libgcc` has
    been flipped (bazelbuild#6825)
  - Added --incompatible_disable_legacy_crosstool_fields. See the
    migration notes at
    bazelbuild#6861.
  - In the Query HowTo, recommend ":*" instead of ":all". "all" might
    be the name of a target.
  - The default value for --incompatible_strict_action_env has been
    flipped to 'false' again, as we discovered breakages for local
    execution users. We'll need some more time to figure out the best
    way to make this work for local and remote execution. Follow
    bazelbuild#7026 for more details.

This release contains contributions from many people at Google, as well as Benjamin Peterson, Dave Lee, George Gensure, Gert van Dijk, Gustavo Storti Salibi, Keith Smiley, Loo Rong Jie, Lukasz Tekieli, Mikhail Mazurskiy, Thi, Travis Cline, Vladimir Chebotarev, Yannic.

sesmith177 pushed a commit to greenhouse-org/bazel that referenced this issue Feb 1, 2019

Release 0.22.0 (2019-01-28)
Baseline: deb028e

Cherry picks:

   + a3a5975:
     Fix a race condition in remote cache
   + b8d0e1b:
     Use a new GitHub token and KMS key for the release process.
   + 3759e38:
     remote: fix unexpected IO error (not a directory)
   + 4473bb1:
     Fix a race condition in Bazel's Windows process management.
   + 9137fb9:
     undo flag flip of --incompatible_strict_action_env
   + 12ab12e:
     Revert "Enabling Bazel to generate input symlinks as defined by
     RE AP?
   + 6345c74:
     Automated rollback of commit
     30536ba.

New features:

  - Add inputs filtering for aquery
  - https://docs.bazel.build now supports versioned
    documentation. Use the selector at the top of the navigation bar
    to
    switch between documentation for different Bazel releases.
  - build_tar.py in tools/build_defs/pkg now supports a json manifest
    that can be used to add paths that have symbols that can't be
    specified via the command line

Important changes:

  - Added `--incompatible_dont_emit_static_libgcc`
    (bazelbuild#6825)
    Added `--incompatible_linkopts_in_user_link_flags`
    (bazelbuild#6826)
  - mobile-install now works with aapt2. Try it out with `bazel
    mobile-install --android_aapt=aapt2 //my:target`
  - Fixed a mobile-install v1 bug when deploying to Android 9 Pie
    devices. bazelbuild#6814
  - Add a new option --xbinary_fdo to pass xbinary profile.
  - --runs_per_test: place in TESTING documentation category.
  - Adds a clarifying message to test case summary output when all
    test cases pass but the target fails.
  - Fixed mobile-install v1 error when installing an app with native
    libraries onto an Android 9 (Pie) device. See
    bazelbuild/examples#77
  - Fixed issue where error messages from Android manifest merging
    actions were not propagated fully.
  - Add outputs and mnemonic filtering to aquery
  - New incompatible change flag for defaulting to aapt2 in Android
    builds: `--incompatible_use_aapt2_by_default`. To build with
    aapt2 today, pass the flag
    `--incompatible_use_aapt2_by_default=true` or
    `--android_aapt=aapt2`, or set the `aapt_version`  to `aapt2` on
    your `android_binary` or `android_local_test` target.
  - set projectId in all PublishBuildToolEventStreamRequest
  - Flip flag --incompatible_string_is_not_iterable
    (bazelbuild#5830)
  - cc_toolchain.(static|dynamic)_runtime_libs attributes are now
    optional
  - Added --incompatible_disable_runtimes_filegroups
    (bazelbuild#6942).
  - objc_bundle has been removed. Please migrate to rules_apple's
    [apple_bundle_import](https://github.com/bazelbuild/rules_apple/bl
    ob/master/doc/rules-resources.md#apple_bundle_import).
  - The apple_stub_binary rule has been deleted.
  - Incompatible flag `--incompatible_dont_emit_static_libgcc` has
    been flipped (bazelbuild#6825)
  - Incompatible flag `--incompatible_linkopts_in_user_link_flags`
    has been flipped (bazelbuild#6826)
  - Open source aquery & cquery query2 tests
  - Fixed a mobile-install bug where `arm64-v8a` libraries were not
    deployed correctly on `arm64` devices. This was done by enabling
    incremental native lib deployment by default. A previously
    undocumented `--android_incremental_native_libs` flag is removed,
    and is now the regular behavior. See
    bazelbuild#2239
  - Incompatible flag `--incompatible_linkopts_in_user_link_flags`
    has been flipped (bazelbuild#6826)
  - Incompatible flag `--incompatible_dont_emit_static_libgcc` has
    been flipped (bazelbuild#6825)
  - Added --incompatible_disable_legacy_crosstool_fields. See the
    migration notes at
    bazelbuild#6861.
  - In the Query HowTo, recommend ":*" instead of ":all". "all" might
    be the name of a target.
  - The default value for --incompatible_strict_action_env has been
    flipped to 'false' again, as we discovered breakages for local
    execution users. We'll need some more time to figure out the best
    way to make this work for local and remote execution. Follow
    bazelbuild#7026 for more details.

This release contains contributions from many people at Google, as well as Benjamin Peterson, Dave Lee, George Gensure, Gert van Dijk, Gustavo Storti Salibi, Keith Smiley, Loo Rong Jie, Lukasz Tekieli, Mikhail Mazurskiy, Thi, Travis Cline, Vladimir Chebotarev, Yannic.

kyliau added a commit to kyliau/angular that referenced this issue Feb 13, 2019

fix(bazel): Turn on strict action env
This commit fixes a bug whereby recompilation occurs every time `yarn ng build`
or `yarn bazel build ...` is invoked.

This is a temporary solution until # bazelbuild/bazel#7026
is fixed.

@kyliau kyliau referenced this issue Feb 13, 2019

Closed

fix(bazel): Turn on strict action env #28675

4 of 14 tasks complete

mhevery added a commit to angular/angular that referenced this issue Feb 13, 2019

fix(bazel): Turn on strict action env (#28675)
This commit fixes a bug whereby recompilation occurs every time `yarn ng build`
or `yarn bazel build ...` is invoked.

This is a temporary solution until # bazelbuild/bazel#7026
is fixed.

PR Close #28675
@dslomov

This comment has been minimized.

Copy link
Contributor

dslomov commented Feb 15, 2019

Which team handles this?

@hlopko hlopko removed their assignment Feb 18, 2019

@laszlocsomor

This comment has been minimized.

Copy link
Contributor

laszlocsomor commented Feb 18, 2019

@buchgr was interested in flipping this flag, so I'm adding "team-Remote-Exec".

@laszlocsomor laszlocsomor removed their assignment Feb 18, 2019

@laszlocsomor

This comment has been minimized.

Copy link
Contributor

laszlocsomor commented Feb 18, 2019

This flag was flipped back in 0.22.0 so I'm dropping the priority.

bazel-io pushed a commit that referenced this issue Feb 26, 2019

Release 0.23.0 (2019-02-26)
Baseline: 441fd75

Cherry picks:

   + 6ca7763:
     Fix a typo
   + 2310b1c:
     Ignore SIGCHLD in test setup script
   + f9eb1b5:
     Complete channel initialization in the event loop

Incompatible changes:

  - //src:bazel uses the minimal embedded JDK, if you want to
    avoid the extra steps of minimizing the JDK, use //src:bazel-dev
    instead.
  - //src:bazel uses the minimal embedded JDK, if you want to
    avoid the extra steps of building bazel with the minimized JDK,
    use //src:bazel-dev
    instead.
  - The default value of --host_platform and --platforms will be
      changed to not be dependent on the configuration. This means
    that setting
      --cpu or --host_cpu will not affect the target or host platform.
  - Toolchain resolution for cc rules is now enabled via an
    incompatible flag, --incompatible_enable_cc_toolchain_resolution.
    The previous
    flag, --enabled_toolchain_types, is deprecated and will be
    removed.
  - java_(mutable_|)proto_library: removed strict_deps attribute.
  - Python rules will soon reject the legacy "py" struct provider
    (preview by enabling --incompatible_disallow_legacy_py_provider).
    Upgrade rules to use PyInfo instead. See
    [#7298](#7298).
  - java_(mutable_|)proto_library: removed strict_deps attribute.
  - Two changes to native Python rules: 1) `default_python_version`
    and `--force_python` are deprecated; use `python_version` and
    `--python_version` respectively instead. You can preview the
    removal of the deprecated names with
    --incompatible_remove_old_python_version_api. See
    [#7308](#7308). 2) The
    version flag will no longer override the declared version of a
    `py_binary` or `py_test` target. You can preview this new
    behavior with --incompatible_allow_python_version_transitions.
    See [#7307](#7307).

Important changes:

  - There is a new flag available
    `--experimental_java_common_create_provider_enabled_packages`
    that acts as a whitelist for usages of
    `java_common.create_provider`. The constructor will be deprecated
    in Bazel 0.23.
  - [#7024] Allow chaining of the same function type in aquery.
  - Introduces --local_{ram,cpu}_resources, which will take the place
    of --local_resources.
  - [#6930] Add documentation for the aquery command.
  - Incompatible flag `--incompatible_dont_emit_static_libgcc` has
    been flipped (#6825)
  - Incompatible flag `--incompatible_linkopts_in_user_link_flags`
    has been flipped (#6826)
  - Flag --incompatible_range_type is removed.
  - Flag --incompatible_disallow_slash_operator is removed.
  - Flag --incompatible_disallow_conflicting_providers is removed.
  - `--incompatible_disallow_data_transition` is now enabled by
    default
  - Allow inclusion of param files in aquery output
  - [#6985] Add test to verify aquery's behavior for Cpp action
    templates.
  - --incompatible_require_feature_configuration_for_pic was flipped
    (#7007).
  - Also ignore module-info.class in multi-version Jars
  - objc_framework has been deleted. Please refer to
    apple_dynamic_framework_import and apple_static_framework_import
    rules available in
    [rules_apple](https://github.com/bazelbuild/rules_apple/blob/maste
    r/doc/rules-general.md)
  - --test_sharding_strategy=experimental_heuristic is no more
  - objc_bundle_library has been removed. Please migrate to
    rules_apple's
    [apple_resource_bundle](https://github.com/bazelbuild/rules_apple/
    blob/master/doc/rules-resources.md#apple_resource_bundle).
  - You can now use the attribute `aapt_version` or the flag
    `--android_aapt` to pick the aapt version for android_local_test
    tests
  - In --keep_going mode, Bazel now correctly returns a non-zero exit
    code when encountering a package loading error during target
    pattern parsing of patterns like "//foo:all" and "//foo/...".
  - The default value for --incompatible_strict_action_env has been
    flipped to 'false' again, as we discovered breakages for local
    execution users. We'll need some more time to figure out the best
    way to make this work for local and remote execution. Follow
    #7026 for more details.
  - Locally-executed spawns tagged "no-cache" no longer upload their
    outputs to the remote cache.
  - Introduces --host_compiler flag to allow setting a compiler for
    host compilation when --host_crosstool_top is specified.
  - --incompatible_expand_directories is enabled by default
  - [aquery] Handle the case of aspect-on-aspect.
  - Fixed a longstanding bug in the http remote cache where the value
    passed to
    --remote_timeout would be interpreted as milliseconds instead of
    seconds.
  - Enable --incompatible_use_jdk10_as_host_javabase by default, see
    #6661
  - Add --incompatible_use_jdk11_as_host_javabase: makes JDK 11 the
    default --host_javabase for remote jdk
    (#7219)
  - Highlight TreeArtifact in aquery text output.
  - Locally-executed spawns tagged "no-cache" no longer upload their
    outputs to the remote cache.
  - java_common APIs now accept JavaToolchainInfo and JavaRuntimeInfo
    instead of configured targets for java_toolchain and java_runtime
  - cc_common.create_cc_toolchain_config_info is stable and available
    for production use
  - incompatible_use_toolchain_providers_in_java_common: pass
    JavaToolchainInfo and JavaRuntimeInfo providers to java_common
    APIs instead of configured targets
    (#7186)
  - --incompatible_strict_argument_ordering is enabled by default.
  - Bazel now supports reading cache hits from a repository cache,
    even if it doesn't have write access to the cache.
  - Adding arm64e to OSX CROSSTOOL.
  - Ignore package-level licenses on config_setting.
  - Add an optional output_source_jar parameter to java_common.compile
  - --incompatible_disable_objc_provider_resources is now enabled by
    default. This disables ObjcProvider's fields related to resource
    processing.
  - Explicitly set https.protocols and exclude TLSv1.3.
  - Bazel now validates that JAVA_HOME points to a valid JDK and
    falls back to auto-detection by looking up the path of `javac`.
  - Upgrade the embedded JDK version to 11.0.2.
  - Added --incompatible_disable_crosstool_file
    (#7320)
  - --incompatible_disable_objc_provider_resources is now enabled by
    default. This disables ObjcProvider's fields related to resource
    processing.
  - --incompatible_disable_tools_defaults_package has been flipped.
  - For tests that do not generate a test.xml, Bazel now uses a
    separate action to generate one; this results in minor
    differences in the generated test.xml, and makes the generation
    more reliable overall.
  - incompatible_generate_javacommon_source_jar: java_common.compile
    now always generates a source jar, see
    #5824.
  - New incompatible flag
    --incompatible_disallow_struct_provider_syntax removes the
    ability for rule implementation functions to return struct. Such
    functions should return a list of providers instead. Migration
    tracking: #7347

This release contains contributions from many people at Google, as well as Benjamin Peterson, Ed Schouten, erenon, George Gensure, Greg Estren, Igal Tabachnik, Ittai Zeidman, Jannis Andrija Schnitzer, John Millikin, Keith Smiley, Kelly Campbell, Max Vorobev, nicolov, Robin Nabel.

excitoon pushed a commit to KasperskyLab/bazel that referenced this issue Feb 27, 2019

Release 0.23.0 (2019-02-26)
Baseline: 441fd75

Cherry picks:

   + 6ca7763:
     Fix a typo
   + 2310b1c:
     Ignore SIGCHLD in test setup script
   + f9eb1b5:
     Complete channel initialization in the event loop

Incompatible changes:

  - //src:bazel uses the minimal embedded JDK, if you want to
    avoid the extra steps of minimizing the JDK, use //src:bazel-dev
    instead.
  - //src:bazel uses the minimal embedded JDK, if you want to
    avoid the extra steps of building bazel with the minimized JDK,
    use //src:bazel-dev
    instead.
  - The default value of --host_platform and --platforms will be
      changed to not be dependent on the configuration. This means
    that setting
      --cpu or --host_cpu will not affect the target or host platform.
  - Toolchain resolution for cc rules is now enabled via an
    incompatible flag, --incompatible_enable_cc_toolchain_resolution.
    The previous
    flag, --enabled_toolchain_types, is deprecated and will be
    removed.
  - java_(mutable_|)proto_library: removed strict_deps attribute.
  - Python rules will soon reject the legacy "py" struct provider
    (preview by enabling --incompatible_disallow_legacy_py_provider).
    Upgrade rules to use PyInfo instead. See
    [bazelbuild#7298](bazelbuild#7298).
  - java_(mutable_|)proto_library: removed strict_deps attribute.
  - Two changes to native Python rules: 1) `default_python_version`
    and `--force_python` are deprecated; use `python_version` and
    `--python_version` respectively instead. You can preview the
    removal of the deprecated names with
    --incompatible_remove_old_python_version_api. See
    [bazelbuild#7308](bazelbuild#7308). 2) The
    version flag will no longer override the declared version of a
    `py_binary` or `py_test` target. You can preview this new
    behavior with --incompatible_allow_python_version_transitions.
    See [bazelbuild#7307](bazelbuild#7307).

Important changes:

  - There is a new flag available
    `--experimental_java_common_create_provider_enabled_packages`
    that acts as a whitelist for usages of
    `java_common.create_provider`. The constructor will be deprecated
    in Bazel 0.23.
  - [bazelbuild#7024] Allow chaining of the same function type in aquery.
  - Introduces --local_{ram,cpu}_resources, which will take the place
    of --local_resources.
  - [bazelbuild#6930] Add documentation for the aquery command.
  - Incompatible flag `--incompatible_dont_emit_static_libgcc` has
    been flipped (bazelbuild#6825)
  - Incompatible flag `--incompatible_linkopts_in_user_link_flags`
    has been flipped (bazelbuild#6826)
  - Flag --incompatible_range_type is removed.
  - Flag --incompatible_disallow_slash_operator is removed.
  - Flag --incompatible_disallow_conflicting_providers is removed.
  - `--incompatible_disallow_data_transition` is now enabled by
    default
  - Allow inclusion of param files in aquery output
  - [bazelbuild#6985] Add test to verify aquery's behavior for Cpp action
    templates.
  - --incompatible_require_feature_configuration_for_pic was flipped
    (bazelbuild#7007).
  - Also ignore module-info.class in multi-version Jars
  - objc_framework has been deleted. Please refer to
    apple_dynamic_framework_import and apple_static_framework_import
    rules available in
    [rules_apple](https://github.com/bazelbuild/rules_apple/blob/maste
    r/doc/rules-general.md)
  - --test_sharding_strategy=experimental_heuristic is no more
  - objc_bundle_library has been removed. Please migrate to
    rules_apple's
    [apple_resource_bundle](https://github.com/bazelbuild/rules_apple/
    blob/master/doc/rules-resources.md#apple_resource_bundle).
  - You can now use the attribute `aapt_version` or the flag
    `--android_aapt` to pick the aapt version for android_local_test
    tests
  - In --keep_going mode, Bazel now correctly returns a non-zero exit
    code when encountering a package loading error during target
    pattern parsing of patterns like "//foo:all" and "//foo/...".
  - The default value for --incompatible_strict_action_env has been
    flipped to 'false' again, as we discovered breakages for local
    execution users. We'll need some more time to figure out the best
    way to make this work for local and remote execution. Follow
    bazelbuild#7026 for more details.
  - Locally-executed spawns tagged "no-cache" no longer upload their
    outputs to the remote cache.
  - Introduces --host_compiler flag to allow setting a compiler for
    host compilation when --host_crosstool_top is specified.
  - --incompatible_expand_directories is enabled by default
  - [aquery] Handle the case of aspect-on-aspect.
  - Fixed a longstanding bug in the http remote cache where the value
    passed to
    --remote_timeout would be interpreted as milliseconds instead of
    seconds.
  - Enable --incompatible_use_jdk10_as_host_javabase by default, see
    bazelbuild#6661
  - Add --incompatible_use_jdk11_as_host_javabase: makes JDK 11 the
    default --host_javabase for remote jdk
    (bazelbuild#7219)
  - Highlight TreeArtifact in aquery text output.
  - Locally-executed spawns tagged "no-cache" no longer upload their
    outputs to the remote cache.
  - java_common APIs now accept JavaToolchainInfo and JavaRuntimeInfo
    instead of configured targets for java_toolchain and java_runtime
  - cc_common.create_cc_toolchain_config_info is stable and available
    for production use
  - incompatible_use_toolchain_providers_in_java_common: pass
    JavaToolchainInfo and JavaRuntimeInfo providers to java_common
    APIs instead of configured targets
    (bazelbuild#7186)
  - --incompatible_strict_argument_ordering is enabled by default.
  - Bazel now supports reading cache hits from a repository cache,
    even if it doesn't have write access to the cache.
  - Adding arm64e to OSX CROSSTOOL.
  - Ignore package-level licenses on config_setting.
  - Add an optional output_source_jar parameter to java_common.compile
  - --incompatible_disable_objc_provider_resources is now enabled by
    default. This disables ObjcProvider's fields related to resource
    processing.
  - Explicitly set https.protocols and exclude TLSv1.3.
  - Bazel now validates that JAVA_HOME points to a valid JDK and
    falls back to auto-detection by looking up the path of `javac`.
  - Upgrade the embedded JDK version to 11.0.2.
  - Added --incompatible_disable_crosstool_file
    (bazelbuild#7320)
  - --incompatible_disable_objc_provider_resources is now enabled by
    default. This disables ObjcProvider's fields related to resource
    processing.
  - --incompatible_disable_tools_defaults_package has been flipped.
  - For tests that do not generate a test.xml, Bazel now uses a
    separate action to generate one; this results in minor
    differences in the generated test.xml, and makes the generation
    more reliable overall.
  - incompatible_generate_javacommon_source_jar: java_common.compile
    now always generates a source jar, see
    bazelbuild#5824.
  - New incompatible flag
    --incompatible_disallow_struct_provider_syntax removes the
    ability for rule implementation functions to return struct. Such
    functions should return a list of providers instead. Migration
    tracking: bazelbuild#7347

This release contains contributions from many people at Google, as well as Benjamin Peterson, Ed Schouten, erenon, George Gensure, Greg Estren, Igal Tabachnik, Ittai Zeidman, Jannis Andrija Schnitzer, John Millikin, Keith Smiley, Kelly Campbell, Max Vorobev, nicolov, Robin Nabel.

@buchgr buchgr added P2 and removed P3 labels Mar 4, 2019

@buchgr

This comment has been minimized.

Copy link
Contributor

buchgr commented Mar 4, 2019

I am currently working on summarising the discussion we had on the mailing list in a document. Will share once ready and then hopefully we'll be able to resolve this issue in the 0.24 release!

@buchgr

This comment has been minimized.

Copy link
Contributor

buchgr commented Mar 11, 2019

I have drafted up a document with some ideas that's not ready to share yet, because I hadn't have time to polish it. I am currently focusing on delivering #6862 and once this feature landed, this issue will be my next priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.