Enable Bazelisk Caching.

[zzcgumn]

Caching downloads and some artefacts is expected to speed up our CI pipeline.

[tameware]

I see the latest Windows run was 17 minutes. Is that faster than before the change? Do we have access to a log of build duration over time?

[zzcgumn]

Claude checked build times so there must be a log somewhere, but I need to find out where it is.

[Copilot]

Pull request overview

This PR aims to speed up CI by enabling caching in the shared Bazelisk setup composite action and by reordering the Linux CI steps so default-configuration work (including the .NET binding tests and full test run) happens before non-default Bazel flag builds.

Changes:

• Enable Bazel action/repository caching via bazel-contrib/setup-bazel in the shared setup-bazelisk composite action.
• Reorder Linux CI steps to keep default-config build/test and .NET binding validation together before --define builds that change the active output configuration.
• Keep non-default --define build/test steps grouped at the end for clarity and to avoid impacting steps that rely on the default configuration.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
.github/workflows/ci_linux.yml	Reorders CI steps so default-config tasks run before non-default --define builds.
.github/actions/setup-bazelisk/action.yml	Enables disk-cache and repository-cache to persist build outputs and external repo downloads between CI runs.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[tameware]

I see the latest Windows run was 17 minutes. Is that faster than before the change? Do we have access to a log of build duration over time?

My mistake! It seems so far the caching applies only to the Linux build. We should look into that one too, but my concern is always with the one that's gating throughput.

[tameware]

I see the latest Windows run was 17 minutes. Is that faster than before the change? Do we have access to a log of build duration over time?

My mistake! It seems so far the caching applies only to the Linux build. We should look into that one too, but my concern is always with the one that's gating throughput.

Or at any rate, ci_linux.yml‎ is the only yml file changed…

[zzcgumn]

Or at any rate, ci_linux.yml‎ is the only yml file changed…

Yes, but is only changing the order of the steps to have those that similar things close to each other in the script. It was confusing to read. Speedup is expected for caching.

[zzcgumn]

my concern is always with the one that's gating throughput.

Linux build_and_test was 20 minutes for the release branch. 14 minutes here. Maybe it did benefit from the caching?

[tameware]

my concern is always with the one that's gating throughput.

Linux build_and_test was 20 minutes for the release branch. 14 minutes here. Maybe it did benefit from the caching?

I hope so! Whenever I looked, Windows was the only one pushing 20 minutes.

Cursor was helpful – the gh commands work nicely:

For dds-bridge/dds, previous CI durations are on the Actions runs themselves.

In the GitHub UI

1. Open Actions
2. Pick a workflow (e.g. ci_linux, ci_macos, ci_windows)
3. Open a past run — the header shows total duration
4. Expand jobs/steps for per-job and per-step times

With gh (CLI)

List recent runs with durations:

gh run list --limit 20

Filter by workflow:

gh run list --workflow=ci_linux.yml --limit 20

Inspect one run (includes timing details):

gh run view <run-id>

Job timing only:

gh run view <run-id> --json jobs --jq '.jobs[] | {name, startedAt, completedAt}'

Trends over many runs

GitHub doesn’t chart historical build times by default. Options:

• Export via gh run list / the Actions API and plot yourself
• Use a badge/service (e.g. workflow status badges) or an Actions analytics tool if you want ongoing tracking

If you say which workflow you care about (Linux/macOS/Windows/WASM), I can pull recent durations for it.

[tameware]

% gh run list --limit 100 | grep 'CI – Linux' | awk -F'\t' '{print $8}' | sort
10m38s
12m26s
12m46s
12m53s
13m0s
13m33s
13m39s
13m59s
14m16s
14m21s
14m44s
14m8s
14m9s
15m51s
20m19s
20m21s

[zzcgumn]

I see the latest Windows run was 17 minutes.

I believe the Windows run will benefit from the caching. I think the best way forward is to merge this and check CI run times once we have a bit more data. Do you agree @tameware?

[tameware]

I do. Easy to roll back if need be.