Problem
CI jobs that actions/checkout with submodules: recursive fail before make runs:
Submodule 'impl' (git@github.com:fastfields/fastfields-cpu-impl.git) registered for path 'impl'
remote: Repository not found.
fatal: clone of '…/fastfields-cpu-impl.git' into submodule path 'impl' failed
The default GITHUB_TOKEN is scoped to the single running repo, so it can't clone the private sibling repos referenced as submodules (impl→kernels, the cpu/cuda chains, _fastfields_lib). This blocks the C++ test/build CI and the bind-py build-from-source legs on every PR.
Fix
Pass an explicit cross-repo token to actions/checkout (it's used for both the main clone and the recursive submodule fetch):
- uses: actions/checkout@v5with:
submodules: recursivetoken: ${{ secrets.CI_SUBMODULE_TOKEN }}Secret setup (GitHub Free)
Org secrets can't be shared with private repos on the Free plan, so use a repository secret named CI_SUBMODULE_TOKEN in each repo whose CI checks out submodules:
- Store the secret in:
fastfields-cpu-lib, fastfields-lib, fastfields-cuda-lib, fastfields-bind-py (Settings → Secrets and variables → Actions). - Token: a fine-grained PAT (Resource owner
fastfields, Repository access covering the leaf repos, Contents: Read) or a classic PAT with repo. - Not stored in
fastfields-kernels / -cpu-impl / -cuda-impl — they have no CI. But the token's read scope must include them, since they are what gets cloned.
Alternative that needs no secret: make the leaf repos (kernels, cpu-impl, cuda-impl) public — public submodules clone without auth.
PRs (one per repo, claude/chore-ci-submodule-token)
Wire the token: into the submodule-checkout steps:
fastfields-cpu-lib — test.yamlfastfields-lib — test.yamlfastfields-cuda-lib — test.yamlfastfields-bind-py — test.yaml, docs.yaml, release.yaml
The change is a harmless no-op until the secret exists (empty token = current behaviour), so it can merge ahead of provisioning.
Note: the wrapper repos (-numpy/-torch/-cupy/fastfields) install dlpack via pip install git+…, which doesn't fetch submodules at all — a separate fix (wheel index / vendored build), not this token.
Problem
CI jobs that
actions/checkoutwithsubmodules: recursivefail beforemakeruns:The default
GITHUB_TOKENis scoped to the single running repo, so it can't clone the private sibling repos referenced as submodules (impl→kernels, thecpu/cudachains,_fastfields_lib). This blocks the C++ test/build CI and the bind-py build-from-source legs on every PR.Fix
Pass an explicit cross-repo token to
actions/checkout(it's used for both the main clone and the recursive submodule fetch):Secret setup (GitHub Free)
Org secrets can't be shared with private repos on the Free plan, so use a repository secret named
CI_SUBMODULE_TOKENin each repo whose CI checks out submodules:fastfields-cpu-lib,fastfields-lib,fastfields-cuda-lib,fastfields-bind-py(Settings → Secrets and variables → Actions).fastfields, Repository access covering the leaf repos, Contents: Read) or a classic PAT withrepo.fastfields-kernels/-cpu-impl/-cuda-impl— they have no CI. But the token's read scope must include them, since they are what gets cloned.Alternative that needs no secret: make the leaf repos (
kernels,cpu-impl,cuda-impl) public — public submodules clone without auth.PRs (one per repo,
claude/chore-ci-submodule-token)Wire the
token:into the submodule-checkout steps:fastfields-cpu-lib—test.yamlfastfields-lib—test.yamlfastfields-cuda-lib—test.yamlfastfields-bind-py—test.yaml,docs.yaml,release.yamlThe change is a harmless no-op until the secret exists (empty token = current behaviour), so it can merge ahead of provisioning.
Note: the wrapper repos (
-numpy/-torch/-cupy/fastfields) install dlpack viapip install git+…, which doesn't fetch submodules at all — a separate fix (wheel index / vendored build), not this token.