[8.8.0] Expand tree artifact inputs from metadata in the compact execution log (#30830)

An empty tree artifact whose generating action template expands into no
actions is never materialized on disk when a disk or remote cache is in
use: nothing creates the directory and the `RemoteActionFileSystem` has
no entries for it either. Logging a spawn that has such a tree artifact
as an input then fails the action with

ERROR: Linking _nativedeps/6a5ccd5.so failed: IOException while logging
spawn: .../bin/_objs/biome_proto.upb_minitable/iome (No such file or
directory)

since `expandDirectory` readdirs the directory. This happens while
logging *inputs*, which isn't covered by the try/catch around output
logging added in #30717.

Expand tree artifacts from their `TreeArtifactValue` instead. Their
contents are already known, so this avoids the traversal entirely and
also keeps the log complete for trees whose files aren't materialized
locally. Source directories and filesets keep using the filesystem
traversal.

Fixes
https://github.com/bazelbuild/bazel/issues/22920#issuecomment-5345473352

### Description

### Motivation

### Build API Changes

No

### Checklist

- [x] I have added tests for the new use cases (if any).
- [ ] I have updated the documentation (if applicable).

### Release Notes

RELNOTES: Fixed a build failure with `--execution_log_compact_file` when
a C++ action template has no inputs.

Closes #30816.

PiperOrigin-RevId: 968391836
Change-Id: Id05a603a4e1987eef2c50d7722a8ee5955530e83

(cherry picked from commit df9ab4fa0aa2362d007e586a92bcce477dccaf4e)

8.8.0 adaptation: `InputMetadataProvider` has no `getTreeMetadata` on
this branch, so the pick adds one. It is keyed on the exec path rather
than the `ActionInput` so that the existing
`ActionInputMap#getTreeMetadata(PathFragment)` implements it as is, and
it defaults to `null`, which keeps the filesystem traversal for
providers that can't answer (`StaticInputMetadataProvider`,
`SingleBuildFileCache`). The providers that a spawn is actually logged
with forward to their delegates: `ActionInputMetadataProvider`,
`DelegatingPairInputMetadataProvider` and
`ActionExecutionContext.OverriddenRunfilesPathInputMetadataProvider`.
`internalToUnicode` doesn't exist on this branch either, so paths are
used as is, matching the surrounding code.

Closes #30818

Co-authored-by: Ian (Hee) Cha <heec@google.com>
11 files changed
tree: c5b0302426a47ddbecfa25e4f903a6c818dd54b9
  1. .bazelci/
  2. .github/
  3. examples/
  4. scripts/
  5. site/
  6. src/
  7. third_party/
  8. tools/
  9. .bazelrc
  10. .bazelversion
  11. .gitattributes
  12. .gitignore
  13. AUTHORS
  14. bazel_downloader.cfg
  15. BUILD
  16. CHANGELOG.md
  17. CODE_OF_CONDUCT.md
  18. CODEOWNERS
  19. combine_distfiles.py
  20. combine_distfiles_to_tar.sh
  21. compile.sh
  22. CONTRIBUTING.md
  23. CONTRIBUTORS
  24. distdir.bzl
  25. extensions.bzl
  26. LICENSE
  27. maven_install.json
  28. MODULE.bazel
  29. MODULE.bazel.lock
  30. README.md
  31. repositories.bzl
  32. requirements.txt
  33. SECURITY.md
  34. workspace_deps.bzl
README.md

Bazel

{Fast, Correct} - Choose two

Build and test software of any size, quickly and reliably.

  • Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.

  • One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.

  • Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.

  • Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.

Getting Started

Documentation

Reporting a Vulnerability

To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.

Contributing to Bazel

See CONTRIBUTING.md

Build status