Skip to main content
The following features are supported for both BuildBuddy Workflows and Remote Bazel. Check individual docs for more product-specific features.

Attaching artifacts to remote runs

To provide easy access to artifacts generated during remote runs, BuildBuddy supports a special directory called the artifacts directory. If you write files to this directory, BuildBuddy will automatically upload those files and show them in the UI for the remote run. You can get the path to the artifacts directory using the environment variable $BUILDBUDDY_ARTIFACTS_DIRECTORY.

Usage example

For example, Bazel supports several flags such as --remote_grpc_log that allow writing additional debug logs and metadata files associated with an invocation. To automatically upload these to our UI, you could run a command like:
bazel test //... --remote_grpc_log=$BUILDBUDDY_ARTIFACTS_DIRECTORY/grpc.log
BuildBuddy creates a new artifacts directory for each step executed on the remote runner, and recursively uploads all files in the directory after the step exits.

Common artifacts to upload

Debug Logs

Upload Bazel’s gRPC logs, execution logs, or custom debug output for troubleshooting.

Test Reports

Generate and upload test coverage reports, JUnit XML files, or custom test analytics.

Build Artifacts

Store compiled binaries, packages, or other build outputs for later download.

Performance Data

Upload profiling data, timing reports, or benchmark results.
The $BUILDBUDDY_ARTIFACTS_DIRECTORY environment variable is automatically set by BuildBuddy and points to a directory that’s unique for each step in your workflow or remote bazel command.

Fetching artifacts programmatically

If you’d like to fetch artifacts generated during a remote run programmatically, you can either:
Upload the artifacts to a hosted storage site (like S3), where you can later fetch the files using standard cloud storage APIs.Example:
# Upload to S3
aws s3 cp $BUILDBUDDY_ARTIFACTS_DIRECTORY/my-artifact.bin s3://my-bucket/artifacts/
Artifacts are subject to the same retention policies as other BuildBuddy cache data. Configure your cache retention settings in your organization settings.

Example: Uploading multiple artifacts

Here’s a complete example showing how to upload multiple types of artifacts:
buildbuddy.yaml
actions:
  - name: "Build and test with artifacts"
    triggers:
      push:
        branches:
          - main
    bazel_commands:
      - test //...
    after_commands:
      - name: "Upload artifacts"
        shell: |
          # Copy test outputs
          cp -r bazel-testlogs $BUILDBUDDY_ARTIFACTS_DIRECTORY/
          
          # Generate and upload coverage report
          bazel coverage //... --combined_report=lcov
          cp bazel-out/_coverage/_coverage_report.dat $BUILDBUDDY_ARTIFACTS_DIRECTORY/coverage.lcov
          
          # Upload custom build metadata
          echo '{"build_time": "'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' > $BUILDBUDDY_ARTIFACTS_DIRECTORY/metadata.json

Build docs developers (and LLMs) love