Skip to content

Bind-mount Bazel's outputBase off Windows container's VHDX#53758

Open
rdesgroppes wants to merge 1 commit into
mainfrom
regis.desgroppes/bazel-windows-bind-mount-output-base
Open

Bind-mount Bazel's outputBase off Windows container's VHDX#53758
rdesgroppes wants to merge 1 commit into
mainfrom
regis.desgroppes/bazel-windows-bind-mount-output-base

Conversation

@rdesgroppes

@rdesgroppes rdesgroppes commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Bind-mounts a per-job directory for Bazel's --output_base on Windows CI jobs, instead of leaving it on the container's own scratch disk.

Motivation

As settled in #51154, --output_base must stay container-scoped to avoid concurrent instances racing on the same server lock (bazelbuild/bazel#12591, etc.).

That container-local path is the container's dynamically-expanding and differencing sandbox.vhdx, which has documented allocate-on-write and differencing overhead and no way to be made fixed-size.

Writes there have also hit "not enough space on disk" in earlier bazel:test:windows-amd64 job, well under the configured --storage-opt quota, on hosts otherwise showing hundreds of GB free.

$CI_PROJECT_DIR is already real disk, unique per concurrency slot, and swept at job startup, so no separate uniqueness scheme or cleanup of our own is needed.

Describe how you validated your changes

Ran the real bazel:test:windows-amd64 job with this bind mount in place, where bazel wrote hundreds of MB to tens of GB into C:\bob across several runs with no permission or disk errors, so no additional ACL handling was needed on top of the existing disk-cache ACL fix.

Additional Notes

About There is not enough space on the disk:

  • I confirm that that --storage-opt "size=100GB" genuinely sets the virtual size of the VHDX (via docker inspect, diskpart detail vdisk, and in-container DriveInfo/fsutil), ruling out a silently-capped quota,
  • a broader diagnostic investigation also ruled out host disk saturation, concurrent containers sharing a host, Hyper-V isolation, NTFS quotas, and instance-store volumes,.

The present change is therefore to be considered as a reliability improvement regardless of which mechanism was responsible.

### What does this PR do?
Bind-mounts a per-job directory for Bazel's `--output_base` on Windows
CI jobs, instead of leaving it on the container's own scratch disk.

### Motivation
`--output_base` must stay container-scoped to avoid concurrent instances
racing on the same server lock (bazelbuild/bazel#12591, etc.).

That container-local path is the container's dynamically-expanding and
differencing `sandbox.vhdx`, which has documented allocate-on-write and
differencing overhead
(https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/hyper-v-server/storage-io-performance)
and no way to be made fixed-size.

Writes there have also hit "not enough space on disk" in earlier
`bazel:test:windows-amd64` job, well under the configured
`--storage-opt` quota, on hosts otherwise showing hundreds of GB free.

`$CI_PROJECT_DIR` is already real disk, unique per concurrency slot, and
swept at job startup, so no separate uniqueness scheme or cleanup of our
own is needed.

### Describe how you validated your changes
Ran the real `bazel:test:windows-amd64` job with this bind mount in
place, where `bazel` wrote hundreds of MB to tens of GB into `C:\bob`
across several runs with no permission or disk errors, so no additional
ACL handling was needed on top of the existing disk-cache ACL fix.

### Additional Notes
About [There is not enough space on the disk](https://app.datadoghq.com/logs?query=service%3Agitlab-ci%20%40ci.pipeline.name%3A%22DataDog%2Fdatadog-agent%22%20%22not%20enough%22&agg_m=count&agg_m_source=base&agg_t=count&clustering_pattern_field_path=message&cols=host%2Cservice%2Cci.node.name&index=ci-app-pipeline-logs-gitlab-datadog-agent&messageDisplay=inline&refresh_mode=sliding&storage=hot&stream_sort=time%2Cdesc&viz=stream&from_ts=1782924925026&to_ts=1784220925026&live=true):
- I confirm that that `--storage-opt "size=100GB"` genuinely sets the
  _virtual_ size of the VHDX (via `docker inspect`, `diskpart detail
  vdisk`, and in-container `DriveInfo`/`fsutil`), ruling out a
  silently-capped quota,
- my broader diagnostic investigation also ruled out host disk
  saturation, concurrent containers sharing a host, Hyper-V isolation,
  NTFS quotas, and instance-store volumes,.

The present change is therefore to be considered as a reliability
improvement regardless of which mechanism was responsible.
@rdesgroppes rdesgroppes added changelog/no-changelog No changelog entry needed qa/no-code-change No code change in Agent code requiring validation labels Jul 16, 2026
@dd-octo-sts dd-octo-sts Bot added internal Identify a non-fork PR team/agent-build labels Jul 16, 2026
@github-actions github-actions Bot added the short review PR is simple enough to be reviewed quickly label Jul 16, 2026
@rdesgroppes
rdesgroppes marked this pull request as ready for review July 16, 2026 17:13
@rdesgroppes
rdesgroppes requested a review from a team as a code owner July 16, 2026 17:13
@github-actions github-actions Bot deleted a comment from chatgpt-codex-connector Bot Jul 16, 2026
@dd-octo-sts

dd-octo-sts Bot commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

Files inventory check summary

File checks results against ancestor 3b3183fd:

Results for datadog-agent_7.83.0~devel.git.163.436df56.pipeline.125077402-1_amd64.deb:

No change detected

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

changelog/no-changelog No changelog entry needed internal Identify a non-fork PR qa/no-code-change No code change in Agent code requiring validation short review PR is simple enough to be reviewed quickly team/agent-build

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant