2.2.7. Editor Tooling for Workflow Authoring
💡 First Principle: Workflow YAML has a published JSON schema, so most authoring mistakes — a misspelled key, an invalid runs-on, a malformed matrix — are catchable at write time rather than at run time, if you let your editor do the checking.
The January 2026 objectives explicitly list editor tooling, so know the pieces. The GitHub Actions extension for VS Code provides syntax highlighting, schema-driven validation with inline errors, and IntelliSense for workflow keys, action uses: references, and even an action's declared inputs (read from its action.yml). Signed in, it also surfaces your repository's workflow runs, lets you re-run or cancel them, and completes the names of your configured secrets, variables, and environments.
Underneath it sits the community-maintained JSON schema at SchemaStore, which the YAML extension (redhat.vscode-yaml) applies to anything matching .github/workflows/*.yml. That's what turns run-on: into a red squiggle instead of a workflow that silently never matches a runner. Complementary tools worth recognizing: actionlint (a static checker that also shellchecks your run: blocks — it catches injection-prone interpolations), and act for executing workflows locally against Docker.
The practical exam framing is simply shift left: catching a schema error in the editor costs seconds; catching it after a push costs a queue wait, a runner minute, and a red X on the commit.
⚠️ Exam Trap: Schema validation checks structure, not semantics. A workflow can be perfectly schema-valid and still never run (wrong event), fail at runtime (missing secret), or be insecure (untrusted interpolation). Tooling narrows the error class; it doesn't eliminate testing.
Reflection Question: actionlint shellchecks the contents of run: blocks. Given what 2.2.6 said about when ${{ }} is substituted, why is a linter that understands both YAML and shell uniquely well-placed to catch script injection?
