aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/java/com/google/devtools/build/lib/runtime
Commit message (Collapse)AuthorAge
* Make the @Option annotation depend on the java version of the tagging enums.Gravatar ccalvarin2017-07-18
| | | | | | | The option filters proto dependency can be removed from the OptionsParser. This is in response to option parser users that want to avoid the bazel-internal proto file in their dependencies. RELNOTES: None. PiperOrigin-RevId: 162249778
* BEP: Report configuration for all actionsGravatar Klaus Aehlig2017-07-14
| | | | | | | | | | Whenever we report an action in the build event protocol that has a configuration associated with it, report the configuration as well in the protocol (and not only the checksum, if the configuration is not that of one of the top-level configured targets). Change-Id: I9b085d5381b3c3509b4f3b99c8a77bc8fba6abfe PiperOrigin-RevId: 161789745
* BuildEventWithConfiguration: represent configurations as BuildEventGravatar Klaus Aehlig2017-07-11
| | | | | | | | | | | From a BEP point of view, the only interface of a configuration we care about is its BuildEvent structure. Represent it as such, so that we can move this class to the rest of the buildeventstream module. This is a prerequisite for ActionOwners refering to configurations in the BEP. Change-Id: I6d1c1bf2951aac91607e83cad664553cd6620df8 PiperOrigin-RevId: 161510049
* BEP: Positively identify the last messageGravatar Klaus Aehlig2017-07-10
| | | | | | | | | | | Set an additional flag in the last BEP message to indicate the end of the proto sequence. While the last event is implicit from the child-relation (the sequence of protos is finished, if at least one event is seen and all announced events have occurred in the stream), an explicit marking of the last event simplifies processing. Change-Id: I6554476f975dc9e52fdb27fb3221bd27f6097ed9 PiperOrigin-RevId: 161377092
* Factor out BuildConfigurationCollection.Transitions.getDynamicTransition.Gravatar gregce2017-07-07
| | | | | | | | | | | | This is a legacy dependency on the configuration transition table, which is only needed for static configurations. Dynamic configurations didn't actually use anything in that table: this was just a convenience interface that could have equally been defined somewhere else. So this cl defines it somewhere else. There's still one last dependency: Transitions.configurationHook. We'll tackle that in a followup cl. PiperOrigin-RevId: 161141650
* Explicitly state the default options categories for options used in blaze ↵Gravatar ccalvarin2017-06-29
| | | | | | | | testing. Unlike in the production flags, these flags are only used for internal testing. Tagged them as NO_OP instead of the default UNKNOWN to make it clear that we do not need these to become properly tagged. PiperOrigin-RevId: 160526472
* Allow expansion flags to have values.Gravatar Googler2017-06-28
| | | | | | | This lets us change what it expands based on the argument passed to the flag. RELNOTES: Allows flags that expand to take values. PiperOrigin-RevId: 160298412
* Update the --incompatible_ flag requirements to use the metadata tag.Gravatar ccalvarin2017-06-28
| | | | | | Leave the category for now as the generated docs still do not use the new categorization. PiperOrigin-RevId: 160290297
* Make BuildEventStreamer flushable before first eventGravatar Klaus Aehlig2017-06-26
| | | | | | | | | | | | | | | Make the BuildEventStreamer capable of handling the flush() method, even before the initial build event is seen. This happens, if a lot (more than 10240 bytes) of output is produced before the BuildStartingEvent is generated- This is not unlikely, as the whole option processing happens before the build starts. As the promise of flush() is that the OutErrProvider is cleared, and that all output between two flush() get into separate events, numbered in order, we have to temporarily store a list of stdout/stderr String pairs. RELNOTES: None. PiperOrigin-RevId: 160137478
* Safe-guard against broken client environmentsGravatar Ulf Adams2017-06-19
| | | | | | | | | | | | | | The code previously threw StringIndexOutOfBoundsException if the client env contained just a variable name with no '=' or value. Fixed #3196. Change-Id: I5afcaa398ab2e8bacc709445f50ba363659cadbb Closes #3197. Change-Id: I5afcaa398ab2e8bacc709445f50ba363659cadbb PiperOrigin-RevId: 159222809
* BES: Consolidate BuildEventServiceModule and BuildEventStreamerModule.Gravatar buchgr2017-06-14
| | | | | | | | | | | | | | After having open sourced the Build Event Service code, there is no more need to have two separate bazel modules that both create a BuildEventStreamer. This change merges the BuildEventStreamerModule logic into the BuildEventServiceModule. DELTA=677 (330 added, 316 deleted, 31 changed) DELTA_BY_EXTENSION=java=293,oss=32 RELNOTES: None. PiperOrigin-RevId: 158960687
* Move InvocationPolicy to the options parser package.Gravatar ccalvarin2017-06-09
| | | | | | | | | | | | | | It was originally included in runtime due to external dependencies, and a desire to keep the options parser a general options library. These dependencies have been or will be removed, and there are plenty of other general flag libraries. InvocationPolicy is fundamentally acting on the properties of this specific OptionsParser and needs proper access to it for the proper solution to a number of existing bugs, which means having access to things that should be package private. PiperOrigin-RevId: 158523111
* Use ImmutableList for Option expansion functionsGravatar Googler2017-06-08
| | | | | RELNOTES: None PiperOrigin-RevId: 158279811
* Remove the CommandEnvironment from BlazeCommand.editOptionsGravatar ulfjack2017-06-06
| | | | | | | | | | | BlazeCommand.editOptions is currently called fairly late in the startup process, so it must be restrictive in what it does, as any change to the options can potentially introduce inconsistencies between different parts of Bazel. Removing the CommandEnvironment reduces the amount of damage it can do, and may allow us to move the call earlier in the startup process (maybe even to a point where the CommandEnvironment does not exist yet). PiperOrigin-RevId: 158133862
* Migrate Java tests to Truth.Gravatar lberki2017-05-30
| | | | | | RELNOTES: None. PiperOrigin-RevId: 157446717
* Experimental UI: Support multiple BuildEventTransportAnnouncedEventsGravatar buchgr2017-05-29
| | | | | | | | We initially didn't consider that multiple BuildEventStreamer instances might exist during a build. RELNOTES: None. PiperOrigin-RevId: 157385069
* Automated g4 rollback of commit c4134802dd15d6ef5cca6521f6bf6aac395ee2ad.Gravatar kchodorow2017-05-23
| | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Roll forward of directory name change *** Original change description *** Automated g4 rollback of commit 1d9e1ac90197b1d3d7b137ba3c1ada67bb9ba31b. *** Reason for rollback *** Breaks //src/test/shell/integration:force_delete_output_test *** Original change description *** Symlink output directories to the correct directory name If the workspace directory is /path/to/my/proj and the name in the WORKSPACE file is "floop", this will symlink the output directories to output_base/execroot/floop instead of output_base/execroot/proj. More prep for #1262, fixes #1681. PiperOrigin-RevId: 156892980
* BEP: Provide infrastructure to report configurationsGravatar Klaus Aehlig2017-05-08
| | | | | | | | | | In preparation to support multi-configuration builds, provide infrastructure allowing build events to reference BuildConfigurations. The streaming mechanism will ensure that build configurations are introduced in the stream before being referenced for the first time. Change-Id: I6b96fbebc76a05eff4f75a07e8a9cfbcd57f9c22 PiperOrigin-RevId: 155368666
* Rollforward of commit aa7f9307636d38cbb93a03acac8f4c59adfa0ee8.Gravatar ccalvarin2017-05-04
| | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Filter out conflicting flag policies for applicable commands. Only enforce the filtered, applicable policy. *** Original change description *** Automated g4 rollback of commit aa7f9307636d38cbb93a03acac8f4c59adfa0ee8. *** Reason for rollback *** Broke --experimental_inmemory_dotd_files *** Original change description *** Filter out conflicting flag policies before invocation policy enforcement. This is to minimize the likelihood of obscure policy conflict. Now, the last policy on a flag (after policy expansion) will be the only one in the "canonical" invocation policy. There should be no reason for explicitly setting multiple policies on a single flag, but if an expansion flag is policy'd and one of its children has a more specific policy on it, make sure that the policy on the child flag is after the policy on the expansion flag. Note that this restriction (only the last policy gets applied) also applies for repeatable flags. Make sure all values being set to a repeatable flag are set in a single SetValue operation, with multiple flagValues set. PiperOrigin-RevId: 154969189
* BuildEventStreamer: support also providing stdout/stderrGravatar Klaus Aehlig2017-05-02
| | | | | | | | | | | | | Extend the build-event streamer to also report about stdout/stderr, if provided. This information is reported in the progress events. At the moment, we only report stdout/stderr in progress events we send anyway, but the interface is generic enough that we could add time-based reporting later, if needed. Also note, that at the end of the build, we report the final progress event, so that all stdout/stderr generated before the build-complete event get also reported in the build-event protocol. Change-Id: If5dbd59c151edbce02d0a9b2e5938b63c0a5dc58 PiperOrigin-RevId: 154811110
* Automated g4 rollback of commit aa7f9307636d38cbb93a03acac8f4c59adfa0ee8.Gravatar ajmichael2017-04-28
| | | | | | | | | *** Reason for rollback *** Broke --experimental_inmemory_dotd_files RELNOTES: None PiperOrigin-RevId: 154477949
* Automated g4 rollback of commit d9fea57268ff01c001fbcbdc2bd057c86c362e6f.Gravatar buchgr2017-04-25
| | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Rollforward with fix for test flakiness. BEP transport closed events are delivered via their own threadpool and thus might not have been sent immediately. BuildEventStreamerTest#testSimpleStream now waits for a bit until the event has been delivered. I ran the test with --runs_per_test=1000 several times and had no further failures. *** Original change description *** Automated g4 rollback of commit 3d596d63f883fff56001ed7b2e5cf51dba45f082. *** Reason for rollback *** Made BuildEventStreamerTest#testSimpleStream 3% flaky based on --runs_per_test=1000. RELNOTES: None PiperOrigin-RevId: 154170833
* Automated g4 rollback of commit 3d596d63f883fff56001ed7b2e5cf51dba45f082.Gravatar ajmichael2017-04-25
| | | | | | | | *** Reason for rollback *** Made BuildEventStreamerTest#testSimpleStream 3% flaky based on --runs_per_test=1000. RELNOTES: None PiperOrigin-RevId: 154090559
* BEP: Show protocol upload in the UIGravatar buchgr2017-04-24
| | | | | | | | | | | | | | | | | | | | | | The BEP (build event protocol) upload may at times take longer than the build itself. This is especially true for cached builds, where there is little build work, but the protocol still needs to be uploaded. In this case the bazel UI will now display that it's waiting for BEP upload, both in the current and the new experimental UI (--experimental_ui). When executing a run command, blaze waits for the BEP upload to finish before it runs the target. Major Modifications: - The BuildEventTransport interface now also has a name() method that returns a string. When waiting for a transport to finish the BEP upload, this string is displayed in the UI. - The BuildEventStreamer now emits two new events AnnounceBuildEventTransportsEvent and BuildEventTransportClosed on the event bus. This is how the experimental UI is informed about BEP upload progress. RELNOTES: None PiperOrigin-RevId: 154052401
* Filter out conflicting flag policies before invocation policy enforcement.Gravatar ccalvarin2017-04-20
| | | | | | | | | | | | | This is to minimize the likelihood of obscure policy conflict. Now, the last policy on a flag (after policy expansion) will be the only one in the "canonical" invocation policy. There should be no reason for explicitly setting multiple policies on a single flag, but if an expansion flag is policy'd and one of its children has a more specific policy on it, make sure that the policy on the child flag is after the policy on the expansion flag. Note that this restriction (only the last policy gets applied) also applies for repeatable flags. Make sure all values being set to a repeatable flag are set in a single SetValue operation, with multiple flagValues set. PiperOrigin-RevId: 153584034
* Fix an expansion flag issue where it expands to a repeatable flag.Gravatar ccalvarin2017-04-18
| | | | | | | | There's no reason an expansion flag should not expand to multiple values for a repeatable flag (a flag with allowMultiple set to true.) If this expansion flag is set in a SetValue policy, group its repeatable subflags into a single SetValue per subflag. For an overridable SetValue policy on an expansion, any repeatable flag that it expands to should append its value, and not override the user's original values. PiperOrigin-RevId: 153233784
* Add --all_incompatible_changes invocation policy test.Gravatar ccalvarin2017-04-11
| | | | | | By the time the invocation policy gets enforced, the expansion flag should have been expanded, and policy should act as on any other expansion flag. PiperOrigin-RevId: 152692831
* BEP: Extend infrastructure to allow reporting artifacts only onceGravatar Klaus Aehlig2017-04-07
| | | | | | | | | | Extend the functionality of the BuildEventStreamer to report those parts of NestedSets of Artifacts not reported earlier. In this way, duplicate reporting can be avoided, without the events themselves having to know which artifacts are known already. Change-Id: Ia959c28c440301860eac57ea5d9a712c0d49ebdf PiperOrigin-RevId: 152497672
* BEP: Improve the BuildEventTransport interface.Gravatar buchgr2017-04-07
| | | | | | | | | | | | | | | | Better specify the BuildEventTransport interface. Besides clarifying threading and blocking issues, this change also clarifies error handling/reporting. After several discussions we concluded that the BuildEventTransport interface should not provide error reporting / handling facilities, as there is not much bazel could do with this information. Instead, a transport may decide for itself if an error is fatal and abort the build or if an error should be logged to the user's terminal or if it should be ignored. Furthermore, changing the close() method lays the groundwork for an upcoming change that will report the transport shutdown status to the user command line. PiperOrigin-RevId: 152408938
* Refactor all ctor callsites of PathFragment to instead call a static ↵Gravatar nharmata2017-04-05
| | | | | | | | | | | | 'create' method. This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment). This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations. RELNOTES: None PiperOrigin-RevId: 152145768
* BEP: provide events a generic converter classGravatar aehlig2017-04-04
| | | | | | | | | | | Change the BuildEvent interface to accept a generic class of converters. In this way, we won't have to change it again in the future, once more converters are needed. In fact, a new converter is needed right now (will be added in a follow-up patch) to allow build events to know the name of named artifact groups already reported in the stream. Change-Id: Ibb32ea5fff361e21bcf2d34818d8351a1da7a2e3 PiperOrigin-RevId: 152131870
* Automated g4 rollback of commit 1d9e1ac90197b1d3d7b137ba3c1ada67bb9ba31b.Gravatar hlopko2017-04-04
| | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks //src/test/shell/integration:force_delete_output_test *** Original change description *** Symlink output directories to the correct directory name If the workspace directory is /path/to/my/proj and the name in the WORKSPACE file is "floop", this will symlink the output directories to output_base/execroot/floop instead of output_base/execroot/proj. More prep for #1262, fixes #1681. PiperOrigin-RevId: 152126545
* Add --all_incompatible_changes, the user's shorthand for turning on all ↵Gravatar brandjon2017-04-03
| | | | | | | | | | | | --incompatible_* flags Note that if a developer adds a poorly-formatted incompatible change @Option, constructing an OptionsParser will now fail with an unchecked exception. This can cause some unit tests to fail in unexpected ways, but the developer should see an appropriate error message when the server starts up. To be added: A separate integration test that ensures the expansions of --all_incompatible_changes don't clobber each other. RELNOTES: None PiperOrigin-RevId: 151858287
* If --batch, --keep_going, --discard_analysis_cache, and the new ↵Gravatar janakr2017-03-31
| | | | | | | | | | | | | | | --noexperimental_enable_critical_path_profiling flags are all specified, then Bazel will delete Actions from ActionLookupValues as they are executed in order to save memory. Because an already-run action may output an artifact that is only requested later in the build, we need to maintain a way for the artifact to look up the action. But in most cases we don't need to keep the action itself, just its output metadata. Some actions unfortunately are needed post-execution, and so we special-case them. Also includes dependency change with description: Move action out of key. This keeps action references from polluting the graph -- actions are just stored in one SkyValue, instead of being present in SkyKeys. This does mean additional memory used: we have a separate ActionLookupData object per Action executed. That may reach ~24M for million-action builds. PiperOrigin-RevId: 151756383
* Expand Invocation FlagPolicies on expansion flags.Gravatar ccalvarin2017-03-31
| | | | | | | | For SetValue and UseDefault policies on expansion flags or flags with implicitRequirements, expand the policy into policy for each of its sub-flags. For SetValue, this addresses the issue with policies on expansion flags with overridable=true not actually letting user flags overrride the expansion. For UseDefault, this formalizes the behavior where UseDefault will wipe all user-provided flags that expand from a banned expansion flag, and will allow later work to guarantee that a later policy can override the expansion policy's subflags. Since expansion flags do not have value, break if the invocation policy uses AllowValue or DisallowValue on an expansion flag. PiperOrigin-RevId: 151718539
* Symlink output directories to the correct directory nameGravatar kchodorow2017-03-31
| | | | | | | | | | If the workspace directory is /path/to/my/proj and the name in the WORKSPACE file is "floop", this will symlink the output directories to output_base/execroot/floop instead of output_base/execroot/proj. More prep for #1262, fixes #1681. PiperOrigin-RevId: 151712384
* Catch cases where exec fails before WaitForCompletionCommand starts.Gravatar mstaib2017-03-29
| | | | | | | | | | | | | | | | | It's possible for cases to happen where the BlazeCommandDispatcher fails before starting the WaitForCompletionCommand. In these cases, the test's command state handoff will never take place because no command state will be created to be handed off (obviously). This means that runIn will wait forever. Instead, if the command completes and the command state has still not been handed off, set an exception into the command state so that the test will fail without further troubles. RELNOTES: None. PiperOrigin-RevId: 151495494
* Split out the InvocationPolicy parser from the enforcer.Gravatar ccalvarin2017-03-29
| | | | | | The encapsulation was off, since the format in which we accept policy has nothing to do with how we then enforce the policy. PiperOrigin-RevId: 151471747
* Split up InvocationPolicyEnforcerTest.Gravatar Chloe Calvarin2017-03-22
| | | | | | | | It was large and unwieldy - keep common logic in the original file but split out the tests into groups by invocation policy operation type. -- PiperOrigin-RevId: 150759733 MOS_MIGRATED_REVID=150759733
* Clean up InvocationPolicyEnforcerTest.Gravatar Chloe Calvarin2017-03-21
| | | | | | | | Remove magic constants and convert to Truth. -- PiperOrigin-RevId: 150692720 MOS_MIGRATED_REVID=150692720
* BuildEventStreamer: fix handling of postedEvents Gravatar Klaus Aehlig2017-03-21
| | | | | | | | | | | | | Always initialize the set of postedEvents. Also, record the initial event as posted. In this way, the build event streamer can also handle events that should be posted after the BuildStartedEvent but are told the streamer about earlier. -- Change-Id: Ic796f2434434819e6c62633755411527a9dcb7e0 Reviewed-on: https://cr.bazel.build/9451 PiperOrigin-RevId: 150620387 MOS_MIGRATED_REVID=150620387
* Global cleanup change.Gravatar Googler2017-03-14
| | | | | | -- PiperOrigin-RevId: 150051360 MOS_MIGRATED_REVID=150051360
* Don't update the action locality for actions with a null ownerGravatar Ulf Adams2017-03-07
| | | | | | -- PiperOrigin-RevId: 149418372 MOS_MIGRATED_REVID=149418372
* Make ExperimentalStateTracker aware of DownloadProgressEvents Gravatar Klaus Aehlig2017-03-02
| | | | | | | | | | | | In the experimental UI, to be able to report appropriately about ongoing downloads, we need to track their state, as updated by the DownloadProgressEvents. Do so. Also report on ongoing downloads in the progress bar. -- Change-Id: I668e963cd6da85ec598b23724066d366d465271f Reviewed-on: https://cr.bazel.build/9114 PiperOrigin-RevId: 148899297 MOS_MIGRATED_REVID=148899297
* BEP: Add BuildFinished event. Gravatar Jakob Buchgraber2017-02-28
| | | | | | | | | | | | The build event protocol now emits a BuildFinished event at the end of a build. The event is a child of the BuildStarted event. The code changes were larger than expected, due to some refactoring in BuildEventStreamer. This was necessary as the BuildCompleteEvent now implements the BuildEvent interface and Guava's EventBus always invokes the most specialized subscriber method. Thus, the buildEvent(BuildEvent) and buildCompleted(BuildCompletedEvent) methods had to be merged. -- Change-Id: Id0c2bd7220dc8ce03128b7126587e212ee8ce836 Reviewed-on: https://cr.bazel.build/9053 PiperOrigin-RevId: 148788582 MOS_MIGRATED_REVID=148788582
* Support mapping of Paths to URIsGravatar Klaus Aehlig2017-01-18
| | | | | | | | | | | Bazel-created files (like log files of test runs) are internally reported as Paths. However, this is not always the most useful representation of the location of that artifact for a consumer of build events. Therefore, support a mapping of paths to more useful URIs. -- PiperOrigin-RevId: 144843525 MOS_MIGRATED_REVID=144843525
* Fixes invocation policy to correctly apply allow/disallow policies to flagsGravatar Alex Humesky2016-12-16
| | | | | | | | | | | | | which have converters that return lists. The problem was that the policy might, say, disallow values ["a", "b"], and a flag --foo might have a converter which takes a string and splits it by commas to produce a list. The options parser would apply the converter to --foo=a,b to produce ["a", "b"], but invocation policy would compare each element of the policy to the list itself, which will never work. -- PiperOrigin-RevId: 142297177 MOS_MIGRATED_REVID=142297177
* Names of extra-action protos now take into account all aspect names.Gravatar Dmitry Lomov2016-12-16
| | | | | | | | | | | | | If an Aspect registered an action that an extra-action is shadowing, its name is used when creating the extra-action's ID and name. Since recently, an aspect can see other aspects applied to the same target. This CL record the names of other aspects applied to the target as well, disambiguating the action owners. -- PiperOrigin-RevId: 142264153 MOS_MIGRATED_REVID=142264153
* Support ordering constraints on build eventsGravatar Klaus Aehlig2016-11-21
| | | | | | | | | | | | | | In the build event protocol, we promise to respect certain ordering constraints that come naturally by causality anyway (e.g., the root cause of a failure has to come before the failure). However, in the way the call structure is organized, events might occur on the event bus in wrong order. So allow events to specify that order and make the streamer honor it. -- Change-Id: I1fbe9b93681f0ddfa35d9d00d5d1b02103da38a5 Reviewed-on: https://bazel-review.googlesource.com/#/c/7370 MOS_MIGRATED_REVID=139774946
* Make LineBufferedOutputStream resistant to exceptions thrown while flushing ↵Gravatar Lukacs Berki2016-11-21
| | | | | | | its buffer. -- MOS_MIGRATED_REVID=139771073
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-05 11:55:31 +0000