dtourolle
fb4e4d4abc
The traceability job has been failing since it was written, and never on anything it checks. It declared no `container:`, so it ran in the runner's default image, which has no node; act_runner executes JS actions with the node it finds inside the job container, and both actions/checkout and upload-artifact are JS. The job died at "Cannot find: node in PATH" before the repository was checked out, and every later step then failed on an empty working tree -- the summary step's "head: cannot open 'docs/traceability.md'" is that, not a missing report. node:20-bookworm, and the choice is not arbitrary: node is the part with no workaround, while Debian 12 already carries python3.11 (tomllib, so the stdlib-only extractor reads traceability.toml) and git (for the pull_request diff step). Nothing in it names this repo, so the file stays copyable into the other two components unedited, which its header claims and this commit keeps true. The kpnpp-builder and jellytau-builder images bake node in for exactly this reason, and Dockerfile.builder-cpu says so in a comment. That knowledge just had not reached the one job with no image of its own. Second failure behind the first: the jray-project submodule was pinned by SSH URL. The runner has no key, so `submodules: recursive` could not have fetched the extractor even with node present. https, like the KPN submodule beside it. Gate and static check both pass locally on this tree -- 42/72 traced, 73.7% in CI scope, 0 orphans, 0 bare-cosine violations -- so what CI reports next is a fact about CI, not about the tree.
8 lines
245 B
Plaintext
8 lines
245 B
Plaintext
[submodule "external/KPN"]
|
|
path = external/KPN
|
|
url = https://gitea.tourolle.paris/dtourolle/KPN.git
|
|
branch = master
|
|
[submodule "jray-project"]
|
|
path = scripts/vendor/jray-project
|
|
url = https://gitea.tourolle.paris/dtourolle/jray-project.git
|