aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/java/com/google/devtools/build/lib/runtime/BlazeCommandDispatcherRcoptionsTest.java
Commit message (Collapse)AuthorAge
* Remove ConfigurationCollectionFactory as part of the static config cleanup.Gravatar gregce2017-08-18
| | | | PiperOrigin-RevId: 165578449
* 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
* 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
* 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
* Move workspace initialization out of BlazeRuntime.Builder.Gravatar Ulf Adams2016-08-10
| | | | | | | Require all callers to call initWorkspace after BlazeRuntime construction. -- MOS_MIGRATED_REVID=129842292
* Split BlazeDirectories into two classes.Gravatar Ulf Adams2016-08-09
| | | | | | | | | | | | | This is done in preparation for allowing multiple workspaces / commands in a single server. That requires changes to the module API, which currently hard-codes a 1:1 correspondence between workspaces and servers. Note how BlazeDirectories exists even when it runs outside a workspace. It's not ideal that the output base is in ServerDirectories, and the BlazeRuntime creation also still requires a BlazeDirectories instance. -- MOS_MIGRATED_REVID=129736613
* Add a ServerBuilder, and use that in the module API.Gravatar Ulf Adams2016-07-07
| | | | | | | This change is similar to a previous change that introduced WorkspaceBuilder. -- MOS_MIGRATED_REVID=126799657
* Replace Constants.PRODUCT_NAME with a startup option --product_name=bazel and Gravatar Luis Fernando Pino Duque2016-05-31
| | | | | | | | | | | (finally) delete Constants.java. For bazel the file Constants.java is the only source of src/main/java/com/google/devtools/build/lib:common and since it was exporting guava then many dependencies needed to be fixed. -- MOS_MIGRATED_REVID=123648270
* Replace the occurrences of Constants.PRODUCT_NAME for a call toGravatar Luis Fernando Pino Duque2016-05-23
| | | | | | | | | BlazeRuntime#getProductName() or a reference to TestConstants.PRODUCT_NAME for tests. This CL prepares the codebase in order to delete the constant. -- MOS_MIGRATED_REVID=122993568
* Inject the Constants.TOOLS_REPOSITORY in SkylarkRuleClassFunctions.testBaseRule Gravatar Luis Fernando Pino Duque2016-04-29
| | | | | | | | | | | | | via the Skylark and delete the constant. Also, change the isLoadingPhase in the Skylark environment an enum Phase in order to: - Decide whether testRules are enabled or not and, - Check that the toolsRepository is set when in the LOADING phase. Finally, a few tests that were using ConfiguredRuleClassProvider directly had to be updated to set a tools repository, otherwise createGlobals() fails. -- MOS_MIGRATED_REVID=121022804
* Precompute defaults package content to save ~milliseconds every time ↵Gravatar Janak Ramakrishnan2016-04-28
| | | | | | | | | BlazeRuntime#getDefaultsPackageContent is called. Thanks to nharmata for the suggestion. -- MOS_MIGRATED_REVID=120984951
* Block when another command is running on the server and not on the client ↵Gravatar Lukacs Berki2016-04-20
| | | | | | | when in gRPC mode. -- MOS_MIGRATED_REVID=120233121
* Fix bug introduced by commit dc0fbb42ab22ab8f3205b0884069e1ffe03677c9 where ↵Gravatar Nathan Harmata2016-04-07
| | | | | | | | | | | | | a less specific option specification in a rc file could override a more specific option specification when there's a non-trivial Command hierarchy. A concrete example would be a "build --foo=1" line overriding a "test --foo=2" line for a "test" invocation. See the added test for more details. Also fix some typos in BlazeCommandDispatcherRcoptionsTest.java. Note that commit dc0fbb42ab22ab8f3205b0884069e1ffe03677c9 was rolled back in commit 417dad0f1e0d0ed4ccd5f8e52b49eb79937da49d which also incidentally rolled back commit 4f0fbe1b09333806cce76b75214e98c7684766e0. So this change is effectively a roll-forward of both of those, plus the bug fix, plus the typo fixes, and plus a documentation update. -- MOS_MIGRATED_REVID=119276218
* Rollback of commit dc0fbb42ab22ab8f3205b0884069e1ffe03677c9.Gravatar John Field2016-04-07
| | | | | | | | | | | | | | | | | | *** Reason for rollback *** Changed the semantics of local .blazerc handling, requiring a Blaze release rollback ([]). *** Original change description *** Make specific options win over common ones When specifying which command names to parse options for, given the command annotation, ensure that "common" comes first, so that it can be overridden by more specific options. -- MOS_MIGRATED_REVID=119227260
* Add tests documenting the way rc-options are combinedGravatar Klaus Aehlig2016-04-07
| | | | | | | | | | | | | | | | Note that this patch does not change any semantics, it just adds tests. In this way, we have a machine-checkable (hence up to date) documentation of the semantics of how rc options are handled. In particular, our semantics is that - options get collected from all rc files, - more specific options take precedence over less specific ones, and - for equally specific options, the most specific rc file takes precedence. -- Change-Id: I6abadd15eb02a2f952debc3b005668e04dccd62a Reviewed-on: https://bazel-review.googlesource.com/#/c/3241 MOS_MIGRATED_REVID=119083139
* Make specific options win over common onesGravatar Klaus Aehlig2016-03-23
When specifying which command names to parse options for, given the command annotation, ensure that "common" comes first, so that it can be overridden by more specific options. -- Change-Id: I20cd90c098e993580c32297d1e36c8a6c939873a Reviewed-on: https://bazel-review.googlesource.com/#/c/3091 MOS_MIGRATED_REVID=117821257
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 08:17:57 +0000