Skip to content

ci: Refactor merge tests - #622

Draft
samuelburnham wants to merge 9 commits into
mainfrom
ci-balance-merge-tests
Draft

ci: Refactor merge tests#622
samuelburnham wants to merge 9 commits into
mainfrom
ci-balance-merge-tests

Conversation

@samuelburnham

Copy link
Copy Markdown
Member

No description provided.

The "Merge tests" required check is satisfied on pull requests by a stub
job and enforced in the merge queue by merge-tests.yml. Hosting the stub
in ci.yml, which also runs on merge_group, left every merge-group commit
with two check runs of that name: the skipped stub and the real result.
GitHub documents same-named checks across workflows as ambiguous. A
dedicated workflow that triggers only on pull_request emits exactly one
"Merge tests" check per commit in either context, and produces no
skipped jobs anywhere.
A from-scratch base build in the PR benchmark job ran without the Rust
setup action, so it took the tree's `.cargo/config.toml` and compiled
for `-Ctarget-cpu=native` while the PR and main binaries were built for
the fleet's fixed x86-64-v4 baseline. The base toolchain step also only
installed when the two toolchain files differed, although nothing in the
job had installed the PR's toolchain either. Run the shared setup action
before the base build, caching the base workspace on WarpCache, and
always ensure the base tree's own toolchain is present.
The comment header reported the build job's CPU as the run's hardware,
but the fleet mixes CPU models and the measured rows come from other
runners: the PR compile row from the compile job, and a bencher-sourced
base side from bench-main at the base SHA. Each compare table now ends
with one hardware line per side. The compile job carries its host with
the row in the cache entry and run artifact; bench-main caches its
measurement host by SHA and parameters, mirroring the attribution CSV,
and the PR run restores it for a bencher-sourced base. A base run in the
benchmark job is labelled with that job's runner. The build-host summary
is dropped from the comment, since pinned codegen makes it irrelevant.
Lake's Rust build of the Blake3 package runs lean-ffi's bindgen over
lean.h, which failed on the Namespace Ubuntu 26.04 image with every C11
atomic undeclared. bindgen collects include paths from the clang binary
on PATH and passes them as -isystem, while clang-sys loads whichever
libclang it finds; on an image shipping LLVM 20, 21 and 22 those differ,
so clang's stdatomic.h include_nexts the other version's copy, whose
identical include guard skips its body (rust-bindgen #2682, #3316).
Export LIBCLANG_PATH and CLANG_PATH for the newest install that has both
clang and libclang, leaving the defaults where none exists.
Valgrind itself is single-threaded; the job's cost is the portable build
of IxTests it needs, since the shared cache carries AVX-512 codegen the
tool cannot decode. Run it on ubuntu-latest with its own actions/cache
entry for .lake, and temporarily also on pull_request so the build and
restore times can be measured before it takes that role in the merge
queue. prepare and the result job stay gated off pull_request, so the
stub workflow remains the only "Merge tests" check on a PR. The runner
name guard in setup-rust-toolchain now applies only to AVX-512 builds.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant