Part of #108. Found while verifying #130 / PR #134.
.github/workflows/fast_ci.yml is invalid YAML and has never run
Every run of this workflow completes with conclusion: failure and zero jobs — on master as well as on branches:
$ gh run list --workflow=fast_ci.yml --limit 4 --json databaseId,conclusion,headBranch
32047546784 failure fix/130-pytest-config jobs=0
32044795710 failure fix/130-pytest-config jobs=0
32042217818 failure master jobs=0
32037388111 failure master jobs=0
Zero jobs plus a failure conclusion means the run never started: GitHub could not parse the workflow.
$ python -c "import yaml; yaml.safe_load(open('.github/workflows/fast_ci.yml'))"
yaml.scanner.ScannerError: while scanning a simple key
in ".github/workflows/fast_ci.yml", line 89, column 1
could not find expected ':'
tests.yml, real_world_tests.yml and real-world-tests.yml all parse fine. Only this one is broken.
Cause
Three steps open a Python heredoc inside a run: | block but write the Python body at column 0:
- name: Run local executor test
run: |
python -c "
from clustrix import cluster, configure # <-- column 0 ends the block scalar
configure(cluster_type='local')
A YAML block scalar ends as soon as indentation drops below the block's indent, so from clustrix import ... is parsed as a new top-level mapping key and the document blows up.
Affected: lines 88, 106, and 152 (the last inside docker run ... python -c ").
Fix: indent each Python body to sit inside its block scalar. <<'PY' ... PY heredocs would be more robust than python -c " with embedded quotes.
Second defect, latent until the first is fixed
The quick-checks job installs:
pip install black flake8 mypy pytest
then runs:
pytest tests/unit/ -v -m "not real_world and not slow" --timeout=60 -x --tb=short --maxfail=3
--timeout comes from pytest-timeout, which is not installed. Verified in a clean venv: pytest exits 4 with error: unrecognized arguments: --timeout=60. So repairing the YAML alone will simply move the failure. Add pytest-timeout to that install line.
Third thing to expect
Once the workflow actually runs, local-integration executes a real @cluster(cores=2) function and asserts the result. Given #120 ("local auto-parallelization silently no-ops"), that step may legitimately fail. Repairing this workflow should therefore be sequenced with #120 rather than treated as a pure YAML fix.
Why this was not fixed in PR #134
That PR is scoped to the pytest configuration. Turning on a workflow that has never executed — one whose jobs will run real @cluster execution and a Docker build — is an unpredictable blast radius that would obscure the config change. I initially added the pytest-timeout line there and reverted it: the diagnosis behind it was wrong (I attributed the workflow's failure to the missing plugin, when in fact it never parses), and a fix that cannot be exercised should not ship with a misleading comment attached.
Acceptance criteria
Part of #108. Found while verifying #130 / PR #134.
.github/workflows/fast_ci.ymlis invalid YAML and has never runEvery run of this workflow completes with
conclusion: failureand zero jobs — onmasteras well as on branches:Zero jobs plus a failure conclusion means the run never started: GitHub could not parse the workflow.
tests.yml,real_world_tests.ymlandreal-world-tests.ymlall parse fine. Only this one is broken.Cause
Three steps open a Python heredoc inside a
run: |block but write the Python body at column 0:A YAML block scalar ends as soon as indentation drops below the block's indent, so
from clustrix import ...is parsed as a new top-level mapping key and the document blows up.Affected: lines 88, 106, and 152 (the last inside
docker run ... python -c ").Fix: indent each Python body to sit inside its block scalar.
<<'PY' ... PYheredocs would be more robust thanpython -c "with embedded quotes.Second defect, latent until the first is fixed
The
quick-checksjob installs:pip install black flake8 mypy pytestthen runs:
pytest tests/unit/ -v -m "not real_world and not slow" --timeout=60 -x --tb=short --maxfail=3--timeoutcomes frompytest-timeout, which is not installed. Verified in a clean venv: pytest exits 4 witherror: unrecognized arguments: --timeout=60. So repairing the YAML alone will simply move the failure. Addpytest-timeoutto that install line.Third thing to expect
Once the workflow actually runs,
local-integrationexecutes a real@cluster(cores=2)function and asserts the result. Given #120 ("local auto-parallelization silently no-ops"), that step may legitimately fail. Repairing this workflow should therefore be sequenced with #120 rather than treated as a pure YAML fix.Why this was not fixed in PR #134
That PR is scoped to the pytest configuration. Turning on a workflow that has never executed — one whose jobs will run real
@clusterexecution and a Docker build — is an unpredictable blast radius that would obscure the config change. I initially added thepytest-timeoutline there and reverted it: the diagnosis behind it was wrong (I attributed the workflow's failure to the missing plugin, when in fact it never parses), and a fix that cannot be exercised should not ship with a misleading comment attached.Acceptance criteria
python -c "import yaml; yaml.safe_load(open('.github/workflows/fast_ci.yml'))"succeedspytest-timeoutinstalled inquick-checksactionlintin CI, or a unit test thatyaml.safe_loads every file in.github/workflows/)