Agent:claude-fastfields-to-teeny
.github/workflows/test.yaml checks out the harness at a fixed branch:
- name: Check out fastfields-cpu-lib (recursive)uses: actions/checkout@v5with:
repository: fastfields/fastfields-cpu-libref: main # <-- always main
and then pins only the nested kernels submodule to the commit under test. That
is right for a PR against main, but every PR based on the teeny branch is
then built by the pre-teeny-refactor cpu-lib and cpu-impl, which cannot compile
against teeny-branch kernels at all.
Reproduction
Running the workflow's own recipe locally against teeny's tip e579add —
a commit that predates any open PR, so nothing here is a regression:
$ git clone --branch main .../fastfields-cpu-lib cpu-lib && cd cpu-lib
$ git submodule update --init --recursive
$ cd impl/kernels && git checkout --detach e579add && cd ../..
$ make -j2 test CXX=clang++
./impl/kernels/distance/spline.h:3:10: fatal error: 'teeny/teeny.h' file not found
The direct cause is that the two cpu-lib branches differ in exactly the way you'd
expect:
# cpu-lib@main # cpu-lib@teeny
INCLUDES += TEENYDIR ?= impl/kernels/external/teeny
INCLUDES += -I$(TEENYDIR)/include \
-I$(TEENYDIR)/external/cccl/libcudacxx/include
so main's Makefile has no teeny include path, and main's cpu-impl still calls
the pushpull kernels deleted in fastfields/fastfields-kernels#36.
Effect
test-via-cpu-lib shows a red ❌ on every teeny-based PR regardless of the
change. It is not reporting anything about the diff. Until this is fixed the real
gate for those PRs is a local make -C fastfields-cpu-lib clean test on both
compilers against the dev-tree checkout, which needs to be stated in the PR body.
Suggested fix
Pick the harness branch to match the PR's base, e.g.
env:
BASE: ${{ github.event.pull_request.base.ref || github.ref_name }}with:
ref: ${{ (startsWith(env.BASE, 'teeny') || startsWith(env.BASE, 'claude/')) && 'teeny' || 'main' }}or, more robustly, try the same-named branch in cpu-lib/cpu-impl and fall back to
main. Either way both sibling repos (cpu-liband the nested cpu-impl)
have to move together — pinning only kernels is what creates the mismatch.
Deliberately not fixed inside fastfields/fastfields-kernels#54 or fastfields/fastfields-kernels#56: it is a CI-configuration concern,
unrelated to either of those changes, and belongs on its own branch.
Agent:
claude-fastfields-to-teeny.github/workflows/test.yamlchecks out the harness at a fixed branch:and then pins only the nested
kernelssubmodule to the commit under test. Thatis right for a PR against
main, but every PR based on theteenybranch isthen built by the pre-teeny-refactor cpu-lib and cpu-impl, which cannot compile
against teeny-branch kernels at all.
Reproduction
Running the workflow's own recipe locally against
teeny's tipe579add—a commit that predates any open PR, so nothing here is a regression:
The direct cause is that the two cpu-lib branches differ in exactly the way you'd
expect:
so
main's Makefile has no teeny include path, andmain's cpu-impl still callsthe pushpull kernels deleted in fastfields/fastfields-kernels#36.
Effect
test-via-cpu-libshows a red ❌ on everyteeny-based PR regardless of thechange. It is not reporting anything about the diff. Until this is fixed the real
gate for those PRs is a local
make -C fastfields-cpu-lib clean teston bothcompilers against the dev-tree checkout, which needs to be stated in the PR body.
Suggested fix
Pick the harness branch to match the PR's base, e.g.
or, more robustly, try the same-named branch in cpu-lib/cpu-impl and fall back to
main. Either way both sibling repos (cpu-liband the nestedcpu-impl)have to move together — pinning only
kernelsis what creates the mismatch.Deliberately not fixed inside fastfields/fastfields-kernels#54 or fastfields/fastfields-kernels#56: it is a CI-configuration concern,
unrelated to either of those changes, and belongs on its own branch.