| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
I missed these in https://github.com/bazelbuild/bazel/commit/654c77c603c039142d8b257f47bdaf14ac507c47.
RELNOTES: None.
PiperOrigin-RevId: 202706112
|
|
|
|
|
| |
RELNOTES: --[no]allow_undefined_configs no longer exists, passing undefined configs is an error.
PiperOrigin-RevId: 202518987
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 202360925
|
|
|
|
|
|
|
| |
Deprecates the flag, though it continues to exist as a no-op so that users get a warning before errors.
RELNOTES: --noexpand_configs_in_place is deprecated.
PiperOrigin-RevId: 200572053
|
|
|
|
|
|
|
|
| |
Fixes #5263
RELNOTES: execution strategies line no longer handles differently the case
where all processes have the same strategy.
PiperOrigin-RevId: 198057496
|
|
|
|
|
|
|
| |
The important_outputs field is deprecated, and this adds a flag to disable
its generation entirely.
PiperOrigin-RevId: 197186530
|
|
|
|
|
|
|
| |
TestConfiguration.
RELNOTES:none
PiperOrigin-RevId: 197135911
|
|
|
|
|
|
|
| |
This is in preparation for adding options to the class, which can be used
to modify the behavior of build events posted to the BEP.
PiperOrigin-RevId: 196997573
|
|
|
|
|
|
|
|
|
| |
This constructor was creating an Exception with a null message leading to possible
NullPointerExceptions in a few places in our codebase. The call sites have
been replaced with calls to AbruptException(String message, ExitCode exitCode) with
a meaningful message.
PiperOrigin-RevId: 196973540
|
|
|
|
|
|
|
|
|
| |
This way the documentation logs them correctly as named "bazel," and describes the correct behavior.
Needed for #4502.
RELNOTES: None.
PiperOrigin-RevId: 196837021
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This overrides --bazelrc and --[no]master_bazelrc regardless of order. Like --bazelrc and --[no]master_bazelrc, it cannot be mentioned in an rc file, this would be a contradiction. This flag is useful for testing, and for having a version-agnostic way to turn off all rc files, such as in the canonical command line reporting. Now that blazerc and bazelrc are separate, this is necessary.
If explicit values for --bazelrc or --master_bazelrc are provided which are now ignored, Bazel will warn the user.
#4502
Alternatives considered - We could avoid this flag but would need to have some well-documented, reusable list of the startup flags that effectively come to the same effect. This would be necessary in our integration tests and in the CommandLineEvent and other places where rc files need to be completely disabled for correctness. We decided that this startup option was more straightforward and usable for both users and Bazel devs: it shouldn't be used when more fine-grained control is needed, but provides warnings if users are likely to be confused by the outcome.
RELNOTES: None.
PiperOrigin-RevId: 196750704
|
|
|
|
|
|
| |
and continue to use the embedded JDK as the default host_javabase.
PiperOrigin-RevId: 196471714
|
|
|
|
|
|
|
| |
This is accomplished by moving it to ConfiguredRuleClassProvider. This also suggests a neat way to get rid of logic in ShellConfiguration.Loader() by moving the determination of the shell executable, there, too, but not in this change.
RELNOTES: None.
PiperOrigin-RevId: 192411609
|
|
|
|
|
|
|
| |
This was broken for --config. Doing this properly requires keeping the order in which the options were given, which could be done either by filtering the ordered list according to which values affect the final outcome or by tracking the order correctly. I picked the later: the option order was not explicitly tracked for expansions before but now it is.
RELNOTES: canonicalize-flags no longer reorders the flags
PiperOrigin-RevId: 192132260
|
|
|
|
|
|
|
|
|
| |
encoding the same in ConfiguredRuleClassProvider.
This is a step towards dumbing down BuildConfiguration.Fragment and the ConfigurationFactoryLoader, which is in needed so that we can rewrite C++/Java/Python rules in Skylark without having to introduce the concept of "configuration loader" in Skylark, too.
RELNOTES: None.
PiperOrigin-RevId: 192104912
|
|
|
|
|
|
|
|
| |
This brings it in line with other flags, where a malformed value is an error.
RELNOTES(INC): --config=foo will error if no 'foo' config exists.
PiperOrigin-RevId: 191910781
|
|
|
|
|
|
|
| |
Fixes: 2846
RELNOTES: Bazel now displays information about remote cache hits and execution strategies used in its UI after every build and test, and adds a corresponding line "process stats" to BuildToolLogs in BEP.
PiperOrigin-RevId: 191441770
|
|
|
|
|
|
|
| |
String categories are deprecated, replace this special-cased value with a specific OptionMetadata tag, TRIGGERED_BY_ALL_INCOMPATIBLE_CHANGES.
RELNOTES: None.
PiperOrigin-RevId: 191069412
|
|
|
|
|
|
|
|
|
| |
These have all had a chance to be categorized with the OptionDocumentationCategory enum, and the help output already uses the enum-grouped format.
The "incompatible changes" category has meaning for --all_incompatible_changes and will be removed separately.
RELNOTES: None.
PiperOrigin-RevId: 190773778
|
|
|
|
|
|
| |
are now internal, and the one that https://github.com/bazelbuild/bazel/commit/d350a897f6182d637ea819c41cd292a50c2db53d just snuck in...
PiperOrigin-RevId: 190705224
|
|
|
|
|
|
| |
most elegant solution, but I don't have a better idea.
PiperOrigin-RevId: 190656869
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove Optional<> where it's not needed. It's nice for return values, but IMHO it was overused in this code (e.g. Optional<List<X>> is an anti-pattern, as the list itself can already signal that it is empty).
- Use Bazel's own Path class when dealing with paths, not String or java.io.File.
- Move LinuxSandboxUtil into the "sandbox" package.
- Remove dead code and unused fields.
- Migrate deprecated VFS method calls to their replacements.
- Fix a bug in ExecutionStatistics where a FileInputStream was not closed.
Closes #4868.
PiperOrigin-RevId: 190217476
|
|
|
|
|
|
| |
from the provided defaults in Options classes. These are used to create BuildOptionsDiffForReconstruction, which lets us store only the diffs in our BuildConfigurationValue.Keys.
PiperOrigin-RevId: 190117455
|
|
|
|
|
|
| |
This reduces the size of its serialized representation.
PiperOrigin-RevId: 188597127
|
|
|
|
|
|
|
|
|
| |
Unlike in fixed-point (legacy) expansion of configs, with --expand_configs_in_place we do not use the options parser to parse each config-definition default override - we first find the full expansion and then expand it in place of the original --config=value instance. For this reason though, we don't support space-separation of recursive configs and their values.
The old warning for this was confusing though, and did not provide much guidance. This should be better, now the warning specifies which config is malformed, in what file, and that it expects the "=" character.
RELNOTES: None.
PiperOrigin-RevId: 188509060
|
|
|
|
|
|
|
| |
published via the BEP, instead of only publishing failed actions and extra actions.
RELNOTES: Add a --build_event_publish_all_actions flag to allow all actions to be published via the BEP.
PiperOrigin-RevId: 187683799
|
|
|
|
|
|
|
|
|
|
|
| |
...so that it can use that path to compute other directories in the
output user base, in particular the default location for caches.
The first cache we will add is the hash-index cache for downloads
of external archives, but a spawn cache might be added later in the
output user base as well.
Change-Id: I24b1c33235c8f76ec008ecb1789163de2b2a45be
PiperOrigin-RevId: 187164275
|
|
|
|
|
|
| |
More information: https://github.com/junit-team/junit5/issues/531
PiperOrigin-RevId: 186900384
|
|
|
|
|
|
|
| |
should be shut down in BlazeCommandResult.
RELNOTES: None.
PiperOrigin-RevId: 184678994
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
child of the process where the Blaze client itself was run.
Limitations:
- Untested on Windows; it should work because ExecuteProgram() is implemented there, too, but since Windows doesn't support exec(), there is at least one process in between
Progress towards #2815.
RELNOTES[NEW]: The new "--direct_run" flag on "blaze run" lets one run interactive binaries.
PiperOrigin-RevId: 184528845
|
|
|
|
|
|
|
|
|
|
|
| |
This class represents a root (such as a package path or an output root) used for file lookups and artifacts. It is meant to be as opaque as possible in order to hide the user's environment from sky keys and sky functions.
Roots are used by RootedPaths and ArtifactRoots.
This CL attempts to make the minimum number of modifications necessary to change RootedPath and ArtifactRoot to use these fields. Deprecated methods and invasive accessors are permitted to minimise the risk of any observable changes.
RELNOTES: None
PiperOrigin-RevId: 182271759
|
|
|
|
|
|
| |
This is slightly more descriptive, and we will potentially want to use the name Root for a broader concept shared between ArtifactRoot and RootedPath.
PiperOrigin-RevId: 182082367
|
|
|
|
|
|
|
|
|
|
|
|
| |
The BuildEventStreamer supports a method flush() to report any pending
stdout/stderr in the BEP; in particular, all internal buffers of for
those streams are cleared (and the memory can be reclaimed). If there
are no pending bytes in those streams, however, there is no need to
generate an additional progress event to get rid of the buffered stream
contents. Make flush() a no-op in this case.
Change-Id: Ia8cf8733fdeaf4d1a50488736d2637862e7cb4f5
PiperOrigin-RevId: 181590982
|
|
|
|
|
|
|
|
|
| |
more cases.
Part of #4128.
Change-Id: Ife5e4581f91ac07931d193ed5eaa256aab3ad047
PiperOrigin-RevId: 180826445
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cleans up a legacy API from Bazel's "static configuration" days,
when transition definitions involved deep and complex logic in the
analysis code. That was too much cruft to embed into lib.packages.
But the modern definitions are way simpler and thus easier to embed.
This change only *copies* the existing definitions. Because a lot of
references will have to be updated, we'll migrate the move over a few
changes.
PiperOrigin-RevId: 179859293
|
|
|
|
|
|
|
|
|
| |
If an expanded value overrides an explicit value, users who do not know the contents of the expansion may be surprised. We already warned about this for hard-coded expansions, and this is now applicable for --config expansions as well.
This will only warn when a single-valued option has its value replaced. Options that accumulate multiple values in a list (e.g., --copt) will silently include both explicit and expanded values.
RELNOTES: None.
PiperOrigin-RevId: 179857526
|
|
|
|
|
|
|
| |
be consistent with LinuxSandboxUtil.
RELNOTES: None.
PiperOrigin-RevId: 179758847
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 179705357
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks //src/test/shell/bazel:bazel_sandboxing_test
*** Original change description ***
Use linux-sandbox via the (new) LinuxSandboxUtil.
RELNOTES: None.
PiperOrigin-RevId: 179676894
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 179646155
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 179588174
|
|
|
|
|
|
| |
And fix the tests that were doing this.
PiperOrigin-RevId: 179548691
|
|
|
|
|
|
|
| |
Fixes #4176 (https://github.com/bazelbuild/bazel/issues/4176).
Closes #4236.
PiperOrigin-RevId: 179218605
|
|
|
|
|
|
|
| |
ExecutionStatisticsProvider.
RELNOTES: None.
PiperOrigin-RevId: 178056182
|
|
|
|
|
|
|
|
|
| |
everywhere instead of duplicating process-wrapper --shell_arguments in Blaze.
To avoid a cyclic dependency, I broke up exec/local:local into exec/local:local and exec/local:options.
RELNOTES: None.
PiperOrigin-RevId: 177419268
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For an action, whenever the status or strategy changes, reset
the timer. In this way, we show the time an action spent in the
current state, rather than the total time the action spent since
started. This might give a better picture of what is currently
going on in the system.
Fixes #4089.
Change-Id: I441337cf2eec58702889ac7a6a9ed150708e8c9d
PiperOrigin-RevId: 176497486
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When showing the current actions, the most interesting are those
that are currently being executed, not those that are waiting for
resources or otherwise in the process of being scheduled. Therefore,
show the executing actions at the top of the list. Also add more
visual hints to distinguish executing from non executing actions.
Screenshot
(14:51:21) [160 / 230] 32 actions, 11 running
Compiling lotsofwork/true986.c; 0s linux-sandbox
Compiling lotsofwork/true982.c; 0s linux-sandbox
Compiling lotsofwork/true983.c; 0s linux-sandbox
Executing genrule //lotsofwork:true975_c; 0s linux-sandbox
Compiling lotsofwork/true981.c; 0s linux-sandbox
Linking lotsofwork/true_999; 0s linux-sandbox
Linking lotsofwork/true_996; 0s linux-sandbox
Linking lotsofwork/true_998; 0s linux-sandbox
Compiling lotsofwork/true980.c; 0s linux-sandbox
Compiling lotsofwork/true98.c; 0s linux-sandbox
Executing genrule //lotsofwork:true974_c; 0s linux-sandbox
[Sched] Creating runfiles tree bazel-out/k8-fastbuild/bin/lotsofwork/true_974.runfiles
[Sched] Linking lotsofwork/true_997
[Sched] Linking lotsofwork/true_995
[Sched] Linking lotsofwork/true_99
[Sched] Linking lotsofwork/true_991 ...
Improves on #4089.
Change-Id: I1bc6636d5e53a16151023bba595e38259eb1ac88
PiperOrigin-RevId: 176483192
|
|
|
|
|
|
|
| |
Some flags are relatively immune to repeated mentions, since only the last mention ends up mattering, but in some cases, the values are accumulated. Expanding the same config twice may lead to surprising results, so provide a friendly warning.
RELNOTES: None
PiperOrigin-RevId: 176422758
|
|
|
|
|
|
|
| |
Configs are recursive, but let's be reasonable. If there's an absurdly long list of configs inheritance, warn about it. It is probably unnecessary, and might very well be unintentional and surprising to the user.
RELNOTES: None.
PiperOrigin-RevId: 176405183
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--expand_configs_in_place.
--config options were expanded in a fix-point expansion, where in practice, the flags that --config values expanded to ended up between the normal bazelrc options and the command line's explicit options. Since the options parser has an order-based priority scheme and it accepts multiple mentions of a single-valued option, this conflicts with users' expectations of being able to override these config expansions by using the order in which they are mentioned.
This change makes it possible to expand the config values defined in your bazelrc (or blazerc) files to occur in-place: --stuff --config=something --laterstuff will interpret the options that --config=something expands to as if they had been mentioned explicitly between --stuff and --laterstuff.
In order to not break users relying on complex flag combinations to configure their builds, this behavior will not yet be turned on by default. Instead, use --expand_configs_in_place as a startup flag to test this feature. --announce_rc may be helpful for debugging any differences between the fixed point and in-place expansions. Once you've debugged your problems, add "startup --expand_configs_in_place" to your blazerc to stick to the new behavior.
RELNOTES: Use --expand_configs_in_place as a startup argument to change the order in which --config expansions are interpreted.
PiperOrigin-RevId: 176371289
|