GitHub Actions YAML Validator

It checks for required fields (on, jobs, runs-on, steps), unpinned action versions, hardcoded secrets, missing checkout step, overly broad push triggers, missing permissions blocks, and YAML syntax issues like tab characters. All validation runs in your browser — nothing is sent to any server.

Using @main or @master means your workflow pulls the latest (possibly broken) version of an action on every run. Pin to a specific version tag (e.g. actions/checkout@v4) or a full commit SHA for reproducible, secure builds. Mutable refs are also a supply chain attack vector — a compromised action could inject malicious code into your pipeline.

Never hardcode secrets in workflow YAML. Add them in your repository or organization settings under Settings → Secrets and variables → Actions. Reference them in workflows with ${{ secrets.SECRET_NAME }}. For environment-specific secrets, use environment protection rules.

The concurrency key lets you group related workflow runs and cancel outdated ones. For example: concurrency: { group: 'ci-${{ github.ref }}', cancel-in-progress: true }. This cancels previous CI runs on the same branch when you push again, saving CI minutes and reducing queue buildup.

Add a top-level permissions block with the minimum required. For read-only CI: permissions: { contents: read }. For workflows that publish packages or deploy: grant only the specific write permission needed (e.g. packages: write). Starting from a deny-all base prevents accidental over-permissioning.

If you use 'on: push:' without a branches or paths filter, the workflow runs on every push to any branch. Add branches: [main] or paths: ['src/**'] to scope it. For PRs, pull_request already filters to the target branch by default.