fast_ci.yml is invalid YAML and has never run a single job (0 jobs, failure, on master too) #135

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

• python -c "import yaml; yaml.safe_load(open('.github/workflows/fast_ci.yml'))" succeeds
• The workflow produces a non-zero job count on a PR
• pytest-timeout installed in quick-checks
• All jobs pass, or the failing ones are triaged against Fix broken backends: PBS runs a nonexistent file, local auto-parallelization silently no-ops #120 / Fix the 127 test failures and 8 collection errors that CI never sees #114
• A guard so an unparseable workflow cannot go unnoticed again (e.g. actionlint in CI, or a unit test that yaml.safe_loads every file in .github/workflows/)