| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 160817326
|
|
|
|
|
|
|
|
|
| |
Issue #3265 went unnoticed for a long time, till it was fixed as
a sideeffect of d1c5329ba622b29afd3ab9f670fa17064d493bc0. To avoid
that happing in the future, add a test. Closes #3265.
Change-Id: Ie22a1d4a2f09fd3dcadcbd900795b3e12b7dc461
PiperOrigin-RevId: 160502516
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For SpawnActions, depending on the value of use_default_shell_env,
the specified environment is taken. The shell environment, however,
consists of two parts: a static mapping of variables to values, and
a set of variables where the value is to be taken from the client
environment. Make sure, both parts are set correctly. Fixes #2035.
--
Change-Id: I32253e9bf651b18ca25107edc5fc839813905726
Reviewed-on: https://bazel-review.googlesource.com/#/c/7211
MOS_MIGRATED_REVID=138376914
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently a call to "bazel" in an integration test means calling a (quite
hidden) function in test-setup.sh which actually calls "$bazel" defined
in "shell/bazel/testenv.sh" which is equal to "$(rlocation io_bazel/src/bazel)".
This is extremely confusing and error prone.
The new mechanism is to add a wrapper script to shell/bin called bazel
and export this directory to the PATH.
Moreover, not every test loads the same test environment, for instance consider
how bazel_query_test loads the test environment:
- Load shell/integration/testenv.sh which loads,
- shell/bazel/test-setup.sh which loads,
- shell/bazel/testenv.sh which loads,
- shell/unittest.bash which loads,
- shell/testenv.sh
Again this is error prone and specially hard to understand, in fact
each test writer needs to decide which of these testenv to load.
This change fixes all of this by having only one testenv.sh
and summarizing the test setup in integration_test_setup.sh.
Namely, for any new integration test, the developer
needs to load integration_test_setup to get the environment set up including
the unittest framework (also it helps to attract contributions).
This change also allows to open sourcing client_sigint_test: Since bazel was a
function client_sigint_test was using a wrong process id to interrupt
the build. The problem is that $! returns
bash's id instead of the id of the process running in the background
when using a function instead of an executable.
A few tests needed to be adapted to the new infrastructure.
--
MOS_MIGRATED_REVID=136470360
|
|
|
|
|
|
|
|
|
| |
...to produce 'build --action_env=' statements, not common ones. See also d59bcb633.
--
Change-Id: Ib0fc75ff8991650c43dd72300b3d92a6986b1165
Reviewed-on: https://bazel-review.googlesource.com/#/c/6493
MOS_MIGRATED_REVID=135350639
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=134636896
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add 'bazel info client-env' which outputs entries for the configuration
file that would freeze the current client environment. The main intended use case
is to use 'bazel info client-env >> .bazelrc' to keep the project reproducible
once a suitable value for the environment variables that used to be taken from the
client environment has been found.
--
Change-Id: Ib4d14dd824d223f335a4d4de04ee21c4a3ec4d83
Reviewed-on: https://bazel-review.googlesource.com/#/c/6112
MOS_MIGRATED_REVID=133699234
|
|
|
|
|
|
|
|
|
|
| |
...to determine if actions have been executed; instead, as the UI to
list the subcommands and explicitly look for the action in question.
--
Change-Id: Ic46244c8daec83a7f6b27e09c366df435f36ba96
Reviewed-on: https://bazel-review.googlesource.com/#/c/6070
MOS_MIGRATED_REVID=133130712
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...to determine which actions have to be recomputed based on changes
to the client environment. Note that this change does it the simple way
and reconsideres all actions on a changed client environment, while still
only reexecuting those, where the part that was inherited from the environment
actually did change.
--
Change-Id: Ie1116d094642165e5e959447a6fcf49d19b37d6e
Reviewed-on: https://bazel-review.googlesource.com/#/c/5431
MOS_MIGRATED_REVID=133010705
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...for the variables that supposed to be inherited from it. Note
That with this patch, we take the correct variables, but do not
yet track the dependency on changes to the client environment; this
will happen in a follow up patches.
Also add a test that demonstrates that the client environment rather
than that at startup is taken.
--
Change-Id: I4d33efa8eaf4f8b689c9b7f2130f71309f3343f0
Reviewed-on: https://bazel-review.googlesource.com/#/c/5392
MOS_MIGRATED_REVID=131406356
|
|
dependencies
This option will allow to specify which environment variables are to
be provided to the actions. Environment variables for the options will
become opt-in, i.e., only environment variables explicitly specified
will be provided to the actions. However, the full range of rc-files
will be able to nominate options to be added; to avoid dependency on
the invocation environment, absolute values can be provided as well.
As the configuration now no longer completely determines the action
environment extend it to also declare which environment variables are
to be taken from the client environment. This will be implemented in
follow-up patches.
The transition plan is that the newly added option takes precedence
over the environment variables added by the fragments. This is conservative,
as the new option is not yet used anywhere. Then the effect of the
fragments will be provided by rc-files, and finally, the setupShellEnvironment
Method will be removed from the fragments all together.
Also add some simple tests for static (i.e., independent of the client
environment) setting of action environment variables.
This is the first step towards implementing the design on [Specifying
environment variables for actions](http://bazel.io/designs/2016/06/21/environment.html).
--
Change-Id: I0ad36913b7d357787b4d69e341926806b3fc61bf
Reviewed-on: https://bazel-review.googlesource.com/#/c/4241
MOS_MIGRATED_REVID=131044391
|