buildbuddy-io / buildbuddy

BuildBuddy is an open source Bazel build event viewer, result store, remote cache, and remote build execution platform.

Home Page:https://buildbuddy.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Actions using ctx.actions.declare_directory() are never cached

srdjanstipic opened this issue · comments

Description of the bug:

Buildbudy version: BuildBuddy v2.12.43

Actions using ctx.actions.declare_directory() are never cached.

This bug is also reported as a bazel bug: bazelbuild/bazel#20899
but it looks like possible BuildBuddy bug.

Which category does this issue belong to?

Core

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I am using bazel with remote caching enabled.
First I will show an example that uses declare_file() and is remote cacheable.
Second, I will modify the example to use declare_directory()
and I will show that bazel never caches modified example (even thought it should).
Before each bazel build I will clean all bazel data.

Remote cacheable example:

> ls non_cacheable_target
BUILD  defs.bzl

> cat non_cacheable_target/BUILD
load(":defs.bzl", "generate_output_files_rule")

generate_output_files_rule(name = "output_files")

> cat non_cacheable_target/defs.bzl
def _generate_output_files_rule_impl(ctx):
    generated_output = ctx.actions.declare_file(ctx.attr.name + "/file.txt")
    file_path = generated_output.path

    ctx.actions.run_shell(
        outputs = [generated_output],
        command = "echo Hola1 > " + file_path,
    )

    return [DefaultInfo(files = depset(direct = [generated_output]))]

generate_output_files_rule = rule(
    implementation = _generate_output_files_rule_impl,
)

I build the target like this (first invocation is not cached 1 processwrapper-sandbox):

> bazel clean --expunge; bazel shutdown
> sudo rm -rf external /home/dockeruser/.cache/bazel /home/dockeruser/.cache/bazel_disk_cache/
> bazel build //non_cacheable_target/...
INFO: Starting clean (this may take a while). Consider using --async if the clean takes more than several minutes.
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
INFO: Analyzed target //non_cacheable_target:output_files (8 packages loaded, 14 targets configured).
INFO: Found 1 target...
Target //non_cacheable_target:output_files up-to-date:
  bazel-bin/non_cacheable_target/output_files/file.txt
INFO: Elapsed time: 7.775s, Critical Path: 0.18s
INFO: 2 processes: 1 internal, 1 processwrapper-sandbox.

I build the same target again (second invocation is cached 1 remote cache hit):

> bazel clean --expunge; bazel shutdown
> sudo rm -rf external /home/dockeruser/.cache/bazel /home/dockeruser/.cache/bazel_disk_cache/
> bazel build //non_cacheable_target/...
INFO: Starting clean (this may take a while). Consider using --async if the clean takes more than several minutes.
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
INFO: Analyzed target //non_cacheable_target:output_files (8 packages loaded, 14 targets configured).
INFO: Found 1 target...
Target //non_cacheable_target:output_files up-to-date:
  bazel-bin/non_cacheable_target/output_files/file.txt
INFO: Elapsed time: 8.140s, Critical Path: 0.07s
INFO: 2 processes: 1 remote cache hit, 1 internal.

Now I modify the example to use declare_directory():

diff --git a/non_cacheable_target/defs.bzl b/non_cacheable_target/defs.bzl
--- a/non_cacheable_target/defs.bzl
+++ b/non_cacheable_target/defs.bzl
@@ -1,6 +1,6 @@
 def _generate_output_files_rule_impl(ctx):
-    generated_output = ctx.actions.declare_file(ctx.attr.name + "/file.txt")
-    file_path = generated_output.path
+    generated_output = ctx.actions.declare_directory(ctx.attr.name)
+    file_path = generated_output.path + "/file.txt"

     ctx.actions.run_shell(
         outputs = [generated_output],

I build the modified example (first invocation is not cached 1 processwrapper-sandbox):

> bazel clean --expunge; bazel shutdown
> sudo rm -rf external /home/dockeruser/.cache/bazel /home/dockeruser/.cache/bazel_disk_cache/
> bazel build //non_cacheable_target/...
INFO: Starting clean (this may take a while). Consider using --async if the clean takes more than several minutes.
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
INFO: Analyzed target //non_cacheable_target:output_files (8 packages loaded, 14 targets configured).
INFO: Found 1 target...
Target //non_cacheable_target:output_files up-to-date:
  bazel-bin/non_cacheable_target/output_files
INFO: Elapsed time: 7.891s, Critical Path: 0.18s
INFO: 2 processes: 1 internal, 1 processwrapper-sandbox.

I build the modified example again (and it is not cached even thought it should be 1 processwrapper-sandbox):

> bazel clean --expunge; bazel shutdown
> sudo rm -rf external /home/dockeruser/.cache/bazel /home/dockeruser/.cache/bazel_disk_cache/
> bazel build //non_cacheable_target/...
INFO: Starting clean (this may take a while). Consider using --async if the clean takes more than several minutes.
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
INFO: Analyzed target //non_cacheable_target:output_files (8 packages loaded, 14 targets configured).
INFO: Found 1 target...
Target //non_cacheable_target:output_files up-to-date:
  bazel-bin/non_cacheable_target/output_files
INFO: Elapsed time: 7.388s, Critical Path: 0.15s
INFO: 2 processes: 1 internal, 1 processwrapper-sandbox.

This is the execution_json_log_file of the last bazel build:

{
  "commandArgs": ["/bin/bash", "-c", "echo Hola1 \u003e bazel-out/k8-dbg/bin/non_cacheable_target/output_files/file.txt"],
  "environmentVariables": [],
  "platform": {
    "properties": []
  },
  "inputs": [],
  "listedOutputs": ["bazel-out/k8-dbg/bin/non_cacheable_target/output_files"],
  "remotable": true,
  "cacheable": true,
  "timeoutMillis": "0",
  "progressMessage": "Action non_cacheable_target/output_files",
  "mnemonic": "Action",
  "actualOutputs": [{
    "path": "bazel-out/k8-dbg/bin/non_cacheable_target/output_files/file.txt",
    "digest": {
      "hash": "9bea9f5b70eb77cb7dc82b9515c68aaa91b7c0cb50122389713fe0c155fd4626",
      "sizeBytes": "6",
      "hashFunctionName": "SHA-256"
    },
    "isTool": false
  }],
  "runner": "processwrapper-sandbox",
  "remoteCacheHit": false,
  "status": "",
  "exitCode": 0,
  "remoteCacheable": true,
  "walltime": "0.005973s",
  "targetLabel": "//non_cacheable_target:output_files"
}

Bazel says that the target is remoteCacheable but it is never cached
and this is the bug.

Which operating system are you running Bazel on?

Linux 4e32033cbff8 5.4.0-1109-azure #115~18.04.1-Ubuntu SMP Mon May 22 20:06:37 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

What is the output of bazel info release?

INFO: Invocation ID: 84276203-854f-4133-80c3-44552407c4a0 release 6.4.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No response

Have you found anything relevant by searching the web?

This bug might be related: bazelbuild/bazel#17162

Any other information, logs, or outputs that you want to share?

No response

I think that the issue is not in buildbuddy but in my BuildBarn settings.
I think that I didn't enable upload of REv2 Directory objects.

Once I am able to find the correct setting, I will update this ticket.

P.S.
BuildBarn version:

    bbSchedulerImage: 'ghcr.io/buildbarn/bb-scheduler:20231212t221000z-fb20d59',
    bbFrontendImage: 'ghcr.io/buildbarn/bb-storage:20231205t110558z-8de3263',
    bbFrontendWithAuthImage: 'ghcr.io/buildbarn/bb-storage:20231205t110558z-8de3263',
    bbStorageImage: 'ghcr.io/buildbarn/bb-storage:20231205t110558z-8de3263',
    bbBrowserImage: 'ghcr.io/buildbarn/bb-browser:20231103t134227z-794e380',
    bbRunnerInstallerImage: 'ghcr.io/buildbarn/bb-runner-installer:20231212t221000z-fb20d59',
    bbWorkerImage: 'ghcr.io/buildbarn/bb-worker:20231212t221000z-fb20d59',

Hey @srdjanstipic, since it's a BuildBarn configuration issue, I'll mark this issue closed - but please feel free to share any updates in case it helps someone else :)