Skip to content
Snippets Groups Projects
Select Git revision
20 results
Search by author
  • Any Author
  • ExcellentOSS ExcellentOSS ExcellentOSS
1 author
This project is mirrored from https://github.com/bazelbuild/bazel.git. Pull mirroring updated .
  1. Jun 22, 2024
  3. Jun 07, 2024
  5. Jun 06, 2024
    • Tobias Werth's avatar
      Delete WORKSPACE file. · 70e80a15
      Tobias Werth authored 
      bzlmod for the win!

Closes #22657.

PiperOrigin-RevId: 640878502
Change-Id: I6dbfc7eefaf3c019407aa18972e552c1e66b6ec8
      70e80a15
    • Googler's avatar
      No public description · 493c5231
      Googler authored 
      PiperOrigin-RevId: 640823721
Change-Id: I3bb76ca2b8d53eb78dec8637bb25fc369852ca7a
      493c5231
    • Matthieu MOREL's avatar
      use bazel_ci_rules bazel_dep instead of http_archive · 7ca7b358
      Matthieu MOREL authored 
      bazel_ci_rules@1.0.0 module has been published to the BCR, see https://github.com/bazelbuild/bazel-central-registry/pull/2058

This use it has a bazel_dep instead of a http_archive

Closes #22618.

PiperOrigin-RevId: 640818741
Change-Id: Ic54471730b371c88e985fe3923646cd880dbe1d2
      7ca7b358
    • Googler's avatar
      Break up build/lib/skyframe:testutils into individual `java_library`s. · 8e095c5b
      Googler authored 
      And rename tests to reflect what they do, not how big they are.

PiperOrigin-RevId: 640811740
Change-Id: I6b412c2ee5053cba39f3456e424c1b06c263bf65
      8e095c5b
    • Googler's avatar
      Split `SkyframeTests` into individual `java_test`s, improve `BUILD`... · de6c4150
      Googler authored 
      Split `SkyframeTests` into individual `java_test`s, improve `BUILD` granularity and test history tracking.

This halves the build time for a single change to a test file (9.6s [1] to 4.9s [2]) by not rebuilding `SkyframeTests_lib` all the time.

This target was added in 2015 (unknown commit) and has been growing since.

Also add a missing `java_test` for `MacOSXFsEventsDiffAwarenessTest.java`. It was excluded from `SkyframeTests_lib` and didn't have a corresponding test target, and all of its test methods was annotated with `@Ignore`. We could also delete it since it hasn't been running at all.

PiperOrigin-RevId: 640810575
Change-Id: I88a37beb64d5908ccd48099bd8a7146026153642
      de6c4150
    • Matt Stark's avatar
      Fix: Correct output_file's actions. · 55cf33ea
      Matt Stark authored 
      It is in fact available from strip.

Closes #22638.

PiperOrigin-RevId: 640762599
Change-Id: I2bb912418ab40311deb1a5e35bb06f3a9bcc388c
      55cf33ea
    • Ted's avatar
      BEGIN_PUBLIC · 93857c1a
      Ted authored 
      Move aar_import helper tools to rules_android

https://github.com/bazelbuild/rules_android/pull/234
END_PUBLIC

RELNOTES: Deleted Bazel's builtin aar_import helper tools. They live in rules_android now.
PiperOrigin-RevId: 640641470
Change-Id: I60f356bffa2fa932079a1a5fe448ad089ce04315
      93857c1a
    • Googler's avatar
      Delete `--incompatible_android_platforms_transition_updated_affected` · 0864fb7f
      Googler authored 
      As far as we understand, this helped resolve actions conflicts in
`AndroidPlatformTransition` when `--output_directory_naming_scheme=legacy` was
set.

`--output_directory_naming_scheme=legacy` is long-since unused. We also aren't
aware of any cases of setting
`--incompatible_android_platforms_transition_updated_affected` to true.

For these reasons, this change aggressivley removes the flag vs. graveyarding
it.

PiperOrigin-RevId: 640617237
Change-Id: Ic4389c34de8f06385d5b1df4f06ac6f866aca38a
      0864fb7f
    • Googler's avatar
      Allow BzlLoadFunction to fully reset the cache. · 25a87d99
      Googler authored 
      Some tests (specifically those that use `usesInliningBzlLoadFunction`) mutate the builtins, and so need to be able to reset the cache, making the comment at [`BzlLoadFunction$InlineCacheManager.reset`](https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/skyframe/BzlLoadFunction.java;drc=2c0faf93deae61bfc0bb1c42becbca4c49c988e6;l=1551) invalid.

Work towards platform-based flags: #19409.

PiperOrigin-RevId: 640607616
Change-Id: I3c30b2888c99b46084ea2519870dc6d61c5a2a79
      25a87d99
    • Fabian Meumertzheim's avatar
      Add a git merge driver for `MODULE.bazel.lock` · 31872501
      Fabian Meumertzheim authored 
      Adds a `jq` script to `scripts/` that merges any number of `MODULE.bazel.lock` files without using Bazel or reading the corresponding `MODULE.bazel` files.

The lockfile docs now have a section explaining the steps needed to set up this script as a custom merger driver for Git, which means that merge conflicts in `MODULE.bazel.lock` files will always be resolved automatically. Note that resolution may emit lockfiles with redundant information that will be dropped by subsequent Bazel invocations.

When Bazel encounters an error during lockfile parsing that could be caused by a merge conflict, it emits a different error message with a link to the docs. This required fixing the following kind of server crash when a conflict marker occurs inside a `recordedFileInputs` object:
```
FATAL: bazel crashed due to an internal error. Printing stack trace:
java.lang.RuntimeException: Unrecoverable error while evaluating node 'com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileValue$$Lambda/0x000000f8011da998@314cd9ee' (requested by nodes 'RegistryKey{url=https://bcr.bazel.build/}')
	at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:557)
	at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:426)
	at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1403)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)
Caused by: java.lang.IllegalArgumentException: the provided path should be absolute in the filesystem
	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:143)
	at com.google.devtools.build.lib.rules.repository.RepoRecordedInput$RepoCacheFriendlyPath.createOutsideWorkspace(RepoRecordedInput.java:202)
	at com.google.devtools.build.lib.rules.repository.RepoRecordedInput$RepoCacheFriendlyPath.parse(RepoRecordedInput.java:222)
	at com.google.devtools.build.lib.rules.repository.RepoRecordedInput$File$1.parse(RepoRecordedInput.java:265)
	at com.google.devtools.build.lib.bazel.bzlmod.GsonTypeAdapterUtil$11.read(GsonTypeAdapterUtil.java:376)
	at com.google.devtools.build.lib.bazel.bzlmod.GsonTypeAdapterUtil$11.read(GsonTypeAdapterUtil.java:367)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41)
	at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:186)
	at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:145)
	at com.google.devtools.build.lib.bazel.bzlmod.DelegateTypeAdapterFactory$1.read(DelegateTypeAdapterFactory.java:133)
	at com.google.devtools.build.lib.bazel.bzlmod.LockFileModuleExtension_GsonTypeAdapter.read(LockFileModuleExtension_GsonTypeAdapter.java:171)
	at com.google.devtools.build.lib.bazel.bzlmod.LockFileModuleExtension_GsonTypeAdapter.read(LockFileModuleExtension_GsonTypeAdapter.java:17)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41)
	at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:187)
	at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:145)
	at com.google.devtools.build.lib.bazel.bzlmod.DelegateTypeAdapterFactory$1.read(DelegateTypeAdapterFactory.java:133)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41)
	at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:187)
	at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:145)
	at com.google.devtools.build.lib.bazel.bzlmod.DelegateTypeAdapterFactory$1.read(DelegateTypeAdapterFactory.java:133)
	at com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileValue_GsonTypeAdapter.read(BazelLockFileValue_GsonTypeAdapter.java:129)
	at com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileValue_GsonTypeAdapter.read(BazelLockFileValue_GsonTypeAdapter.java:15)
	at com.google.gson.Gson.fromJson(Gson.java:991)
	at com.google.gson.Gson.fromJson(Gson.java:956)
	at com.google.gson.Gson.fromJson(Gson.java:905)
	at com.google.gson.Gson.fromJson(Gson.java:876)
	at com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileFunction.getLockfileValue(BazelLockFileFunction.java:93)
	at com.google.devtools.build.lib.bazel.bzlmod.BazelLockFileFunction.compute(BazelLockFileFunction.java:73)
	at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:468)
	... 7 more
```

Alternatives considered:
* Letting Bazel resolve the conflict would require building knowledge about particular version control systems and their conflict style into Bazel. It would also either require the user to resolve conflicts in `MODULE.bazel` first or deviate from the current behavior that the lockfile is not updated when any Bzlmod error is encountered. The jq script can be used as is by every VCS with merge driver support and resolves the conflict in `MODULE.bazel.lock` independently of `MODULE.bazel`.
* Implementing the git merge driver as a `bazel mod` subcommand. This could be the source of intransparent slowdowns during regular git operations, which may even be triggered by other tools such as IDEs. The jq script is very fast.
* Implementing the merger as a Go binary in buildtools would replace the ubiquitous jq tool with a special purpose binary while also not solving the problem that per-user action is required once to register a custom merge driver.

Implements https://docs.google.com/document/d/1TjA7-M5njkI1F38IC0pm305S9EOmxcUwaCIvaSmansg/edit#heading=h.5mcn15i0e1ch

RELNOTES: Git merge conflicts in `MODULE.bazel.lock` files can be resolved automatically. See https://bazel.build/external/lockfile#automatic-resolution for the required setup.

Closes #22428.

PiperOrigin-RevId: 640596606
Change-Id: I20659e3e53a7d8f2529f2ad5a3e7f258d7af026d
      31872501
    • Googler's avatar
      Fix `RuleContext.getToolchainInfo()` · 3c473884
      Googler authored 
      if there is no automatic execution group with the same name as the given toolchain type label, we should search for an automatic execution group that has the given label in its `ToolchainContext.requestedToolchainTypeLabels()`

currently the `ToolchainContext` of a random automatic execution group was returned which may not contain the given toolchain type label.

PiperOrigin-RevId: 640595234
Change-Id: I4f987648b7c7a9794c851739eeaaff55f4499775
      3c473884
    • Googler's avatar
      Update documentation on how target patterns are expanded in... · ffdb7426
      Googler authored 
      Update documentation on how target patterns are expanded in `register_toolchains` and `register_execution_platforms`.

PiperOrigin-RevId: 640583687
Change-Id: I01a8cbe5f994b892fc821443a9ccf8a5924ee4f4
      ffdb7426
    • Fabian Meumertzheim's avatar
      Fix data race in `IndexRegistry#getBazelRegistryJson` · 69361503
      Fabian Meumertzheim authored 
      Should fix the following crash observed in the wild:

```
FATAL: bazel crashed due to an internal error. Printing stack trace:
java.lang.RuntimeException: Unrecoverable error while evaluating node 'RepoSpecKey{moduleKey=rules_pkg@0.7.0, registryUrl=https://bcr.bazel.build/}' (requested by nodes 'com.google.devtools.build.lib.bazel.bzlmod.BazelModuleResolutionValue$$Lambda/0x00000008005fd220@38aba3ca')
        at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:550)
        at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:414)
        at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
Caused by: java.lang.NullPointerException: Cannot invoke "com.google.devtools.build.lib.events.StoredEventHandler.replayOn(com.google.devtools.build.lib.events.ExtendedEventHandler)" because "this.bazelRegistryJsonEvents" is null
        at com.google.devtools.build.lib.bazel.bzlmod.IndexRegistry.getBazelRegistryJson(IndexRegistry.java:336)
        at com.google.devtools.build.lib.bazel.bzlmod.IndexRegistry.getRepoSpec(IndexRegistry.java:295)
        at com.google.devtools.build.lib.bazel.bzlmod.RepoSpecFunction.compute(RepoSpecFunction.java:52)
        at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:461)
        ... 7 more
```

Closes #22639.

PiperOrigin-RevId: 640572972
Change-Id: Id24ce3476df55fa75d6f3291e100b1037f0793f4
      69361503
    • Bazel Release System's avatar
      Release 8.0.0-pre.20240530.1 (2024-06-05) · 98c6c493
      Bazel Release System authored 
      Baseline: b48a3191

Important changes:

  - Changes to environment variables read via `getenv` now correctly
    invalidate module extensions.
  - `--experimental_collect_system_network_usage` is flipped to
    `true`.
  - Progress is no longer written to BEP after the build completing
    event is posted.

This release contains contributions from many people at Google, as well as Alessandro Patti, dependabot[bot], Fabian Meumertzheim, Keith Smiley, Matt Smith, Xdng Yng.
      98c6c493
    • Googler's avatar
      skyfocus: split up working set preparation and execution into discrete steps. · bd2e20af
      Googler authored 
      Also cut down code in `SkyfocusState` with `@AutoBuilder`.

PiperOrigin-RevId: 640547314
Change-Id: Id3655c730601eee06e17182ee51cc6d0b872fa15
      bd2e20af
  7. Jun 05, 2024
  9. Jun 04, 2024
    • Pedro Liberal Fernndez's avatar
      Add option to track sandbox stashes in memory · 1c0135cf
      Pedro Liberal Fernndez authored 
      This change introduces the flag `--experimental_inmemory_sandbox_stashes` to track in memory the contents of the stashes stored with `--reuse_sandbox_directories=true`

With the old behavior Bazel has to perform a lot of I/O to read the contents of each stash before reusing it in a new action. Essentially, it checks  every directory and subdirectory in the stashed sandbox to find out which files are different to the inputs of the new action about to be executed.

With in-memory stashes we associate each stash to the symlinks that needed to be created for that action. We also store the time at which these symlinks were created. In a background thread after the action has finished executing we stat every directory and for the ones that have changed (this should be rare) we update the contents. Because we only read the contents of the directories that have changed we do much less I/O than before.

If an action purposefully changes a sandbox symlink in-place, this won't be detected by statting the directory. I don't know any use case for this since the symlink itself is an implementation detail to achieve sandboxing. For this reason,  manipulation of sandbox symlinks in-place is not supported.

Depending on the build this change might have a significant effect on memory. It should generally improve wall time further in builds where `--reuse_sandbox_directories` already improved wall time.

This change also introduces a minor optimization which is to associate each stash with the target that it was originally created for. When a new action wants to reuse a stash and there is more than one available, it will take the stash whose target is closest to its own. This is done with the assumption that targets that are closer together in the graph will have more inputs in common.

Fixes #22309 .

Closes #22559.

PiperOrigin-RevId: 640142481
Change-Id: Iece2d718df47f403e2fe91c1bd887604eceee8ee
      1c0135cf
    • Googler's avatar
      Simplify naming of transitions in cquery output. · 69802bac
      Googler authored 
      Work towards composable starlark transitions: #22248.

PiperOrigin-RevId: 640136865
Change-Id: Ia4d45e20d4a2bbcff2f625e22b9ab53ec81927ba
      69802bac