mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-10 04:36:40 +00:00
chunk_size() multiplied the runner slots a chunk may assume by the waves the queue window affords, and nothing could say otherwise. The derivation is the right default -- too few rows leaves runners idle, too many push a chunk's tail past the queue cancel -- but a run that wants smaller chunks had to edit default.env to get them. INFINITO_CI_CHUNK_SIZE now takes precedence when it is greater than zero, and zero keeps the derivation. The input travels the same path offset already travels: entry-manual-steer.yml offers the field and maps empty to 0, call-orchestrator.yml hands it to all four chunk blocks, call-test-deploy.yml exports it as the env var. It is a string rather than a number for the reason resume_from_chunk already documents: a workflow_dispatch number input reaches the caller as a string, and a number-typed workflow_call input then makes GitHub refuse the job before it exists. Two places in call-test-deploy.yml set it, not one. The plan summary resolves the chunk size itself, so exporting it only for the app resolution would print a plan that disagrees with the matrix the run then deploys. Measured against the live helper: 0 gives 80 rows over 3 chunks, 25 gives 25 over 4, and returning to 0 restores 80 and 3. The gate found three faults in the first attempt and all three are in this commit: the key sorted after INFINITO_CI_CONCURRENCY rather than before it, the dispatch description ran to 81 characters against a limit of 80, and the retrigger fixture did not carry the new input. That last one matters beyond the test: it is the check that would otherwise let a retrigger drop the chunk size silently. carried_inputs() itself needed nothing, since it derives from the declared inputs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Meta 🧬
Meta-introspection commands that report on roles, applications, services, networks, ports, Jinja templates, and call order across the repository.