GitHub Actions YAML Linter

It checks for: missing on: trigger block, invalid event names, missing jobs: block, broken needs: job references, circular job dependencies, hardcoded tokens/secrets, actions pinned to branch refs instead of version tags, unusual runs-on runner values, secrets printed in echo commands, and tab characters in YAML.

Pinning to @main or @master means your workflow will use whatever code is on that branch at the time it runs — including potentially malicious commits in a supply chain attack. Pinning to a version tag like @v4 or better yet a commit SHA (e.g. @abc1234) ensures your workflow is reproducible and not vulnerable to upstream changes.

The needs: field creates a dependency between jobs. A job with needs: [test, build] will only run after both test and build jobs complete successfully. If a referenced job name doesn't exist, the workflow will fail to parse. This linter catches undefined needs references before you push.

Store secrets in GitHub Settings → Secrets and variables → Actions, then reference them with ${{ secrets.MY_SECRET }}. Never hardcode token values in the workflow YAML. Use GITHUB_TOKEN for operations within the same repository — it's automatically provided and scoped to each workflow run.

Common triggers include push, pull_request, pull_request_target, schedule (cron), workflow_dispatch (manual), workflow_call (reusable), release, issues, issue_comment, create, delete, deployment, and more. Invalid event names will cause the workflow to silently fail to trigger.

No. All linting runs entirely in your browser using JavaScript. Your workflow YAML never leaves your machine — important since workflows often reference sensitive secret names and repository structure.