| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
Apart from updating CustomCommandLineTest this CL is entirely automated.
We also sneak in a rename of addFormat -> addFormatted.
RELNOTES: None
PiperOrigin-RevId: 164870140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Updated to avoid https://github.com/bazelbuild/bazel/issues/3501
This is a rollback of a rollback, with additional
modifications to BazelConfiguration.java to fix
https://github.com/bazelbuild/bazel/issues/3501,
the issue that was the reason we rolled back the
original change.
The additional updates serve to propagate the
client's TMP and TEMP envvars to the action, which
is a short-term solution to allow actions have a
TMP/TEMP envvar on Windows. They need at least one
of those to create temp directories.
The long-term solution is to set a value for TMP
or TEMP in the executor just before executing the
actions, so the TMP/TEMP would not be part of the
action key.
All of this only affects Bazel on Windows.
*** Original change description ***
Automated rollback of commit 0abf5fa2d64c76def5a8fa0f960b73ce0566af4d.
*** Reason for rollback ***
Breaks Bazel CI (https://github.com/bazelbuild/bazel/issues/3501)
*** Original change description ***
Android BusyBox: actions use the default shell env
SpawnActions that run the Android BusyBox now use
the default shell environment.
This has the following benefits:
- Bazel propagates the PATH, TMPDIR envvars to the
action
- Bazel propagates the --action_env envvars to the
action
This allows the Bazel client to pass
--action_env=TMP or --action_env=TEMP (whichever
of the envvars is defined) to the server, so the
BusyBox actions will have TMP/TEMP set (to the
same value as the clientenv), so they can create
temp directories using
java.nio.file.Files.createTempDirectory.
This method seems to be calling the GetTempPath
WinAPI function, which needs the TMP or TEMP
envvar, otherwise it falls back to returning
c:\windows which is non-writable.
There's one drawback of using the default shell
environment, although @ulfjack is working on it:
- PATH is now also part of the action's cache key.
However in a single-machine environment (no
remote execution) and assuming PATH isn't likely
to change between builds, this probably doesn't
poision the action cache in practice.
This change is a short-term solution. Propagating
the client env's TMP/TEMP means we make that part
of the action's cache key.
The ideal long-term solution will be to not
propagate this envvar, and instead let the
execution strategy set it to some
client-env-independent value.
See https://github.com/bazelbuild/bazel/issues/3264
Change-Id: I756a4203b5d86c881bc36cc089e35cde0d419914
RELNOTES: none
PiperOrigin-RevId: 164696600
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, Bazel will always use params files for
some BusyBox tools, because some flags of these
tools expect values with special characters in
them.
We need this change so Bazel can safely pass such
flags to the BusyBox on Windows.
See https://github.com/bazelbuild/bazel/issues/3264
RELNOTES: none
PiperOrigin-RevId: 164582899
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks Bazel CI (https://github.com/bazelbuild/bazel/issues/3501)
*** Original change description ***
Android BusyBox: actions use the default shell env
SpawnActions that run the Android BusyBox now use
the default shell environment.
This has the following benefits:
- Bazel propagates the PATH, TMPDIR envvars to the
action
- Bazel propagates the --action_env envvars to the
action
This allows the Bazel client to pass
--action_env=TMP or --action_env=TEMP (whichever
of the envvars is defined) to the server, so the
BusyBox actions will have TMP/TEMP set...
***
PiperOrigin-RevId: 164126020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SpawnActions that run the Android BusyBox now use
the default shell environment.
This has the following benefits:
- Bazel propagates the PATH, TMPDIR envvars to the
action
- Bazel propagates the --action_env envvars to the
action
This allows the Bazel client to pass
--action_env=TMP or --action_env=TEMP (whichever
of the envvars is defined) to the server, so the
BusyBox actions will have TMP/TEMP set (to the
same value as the clientenv), so they can create
temp directories using
java.nio.file.Files.createTempDirectory.
This method seems to be calling the GetTempPath
WinAPI function, which needs the TMP or TEMP
envvar, otherwise it falls back to returning
c:\windows which is non-writable.
There's one drawback of using the default shell
environment, although @ulfjack is working on it:
- PATH is now also part of the action's cache key.
However in a single-machine environment (no
remote execution) and assuming PATH isn't likely
to change between builds, this probably doesn't
poision the action cache in practice.
This change is a short-term solution. Propagating
the client env's TMP/TEMP means we make that part
of the action's cache key.
The ideal long-term solution will be to not
propagate this envvar, and instead let the
execution strategy set it to some
client-env-independent value.
See https://github.com/bazelbuild/bazel/issues/3264
Change-Id: I756a4203b5d86c881bc36cc089e35cde0d419914
PiperOrigin-RevId: 164114502
|
|
|
|
|
|
|
|
|
|
| |
Consumers using spawn action builder now have access to handy overloads that behind the scene do a lazy String.format. In 95% of cases progress messages are expressible as 0, 1, or 2 argument String.formats.
This saves memory because the format string is constant and shared between all actions, and the captured subjects are usually live on the heap anyway (eg. labels).
Skylark still computes its progress messages eagerly. If we want similar savings there I'd have to follow up with a Skylark proposal.
PiperOrigin-RevId: 164068816
|
|
|
|
|
|
|
| |
With a few manual fixes for readability.
RELNOTES: None.
PiperOrigin-RevId: 160582556
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rolling forward with fixes for the incremental tool.
*** Original change description ***
Automated [] rollback of commit d11d510c571b10787856395709f9ad945ca70bb2.
*** Reason for rollback ***
--
PiperOrigin-RevId: 146940409
MOS_MIGRATED_REVID=146940409
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
--
PiperOrigin-RevId: 146820790
MOS_MIGRATED_REVID=146820790
|
|
|
|
|
|
|
|
|
| |
This makes the code simpler as well as reducing the number of targets to build.
It also makes testing and profiling different action strategies vastly easier.
--
PiperOrigin-RevId: 146812659
MOS_MIGRATED_REVID=146812659
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=134118816
|
|
|
|
|
|
|
| |
RELNOTES: When using android_binary.manifest_merger="android" the merger produces a summary log next to the merged manifest artifact.
--
MOS_MIGRATED_REVID=134082985
|
|
|
|
|
|
|
| |
messages from manifest merging when using manifest_merger="android" on android_binary rules.
--
MOS_MIGRATED_REVID=127962630
|
|
merger that is used (legacy or android) is controlled by the manifest_merger attribute on android_binary and the default is controlled by the --android_manifest_merger flag.
RELNOTES: The Android manifest merger is now available as an option for android_binary rules. The merger will honor tools annotations in AndroidManifest.xml and will perform placeholder substitutions using the values specified in android_binary.manifest_values. The merger may be selected by setting the manifest_merger attribute on android_binary.
--
MOS_MIGRATED_REVID=125603954
|