Skip to content

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

Description

@jeremymanning

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions