github actions

Not specified by the original author.

TL;DR

Invalid workflow file errors are YAML problems or schema problems: indentation, tabs, unquoted special characters (colons, on), or keys GitHub does not recognize. Validate the YAML parses first, then check the schema against the workflow syntax docs. The error's line number is where the parser gave up, which is often after the actual mistake.

The query

GitHub Actions "Invalid workflow file": yaml error debugging

Use this when

• Workflows fail with invalid file errors before running
• The flagged line looks correct
• After editing workflows by hand
• Copy-pasted workflows fail

Not for when

• Jobs that start but fail (runtime errors)
• Action version or input errors at runtime
• Permission errors during runs

Steps

Step 1: Validate the YAML parses

Run the file through a YAML parser locally. If it does not parse, fix the syntax: indentation consistency, no tabs, quoted strings containing colons or special characters. Most failures are here. Expected output: clean YAML parse, or the syntax error located.

Step 2: Check the flagged line's neighbors

The parser reports where it failed, not where the mistake is. Look above the flagged line for unclosed quotes, bad indentation, or a missing colon. Off-by-one-line confusion is the norm. Expected output: the actual mistake found near (not necessarily at) the reported line.

Step 3: Verify against the workflow schema

Check that every key is valid in its position: jobs.[id].steps, uses vs run, recognized event names. A typo in a key name (stpes) fails schema validation with a confusing message. Expected output: all keys valid per the workflow syntax.

Step 4: Watch for YAML gotchas

Quote the word "on" (it parses as boolean true unquoted in YAML 1.1), quote strings with colons, and avoid anchors that GitHub's parser handles differently. These are the classic invisible breakages. Expected output: gotchas eliminated; the file parses under strict YAML too.

Step 5: Use the workflow linter in CI

Add a workflow linting step that validates workflow files on PRs. Invalid workflows should fail the PR that introduces them, not the main branch run that discovers them. Expected output: malformed workflows caught before merge.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UfE0x54aiz4srDMqdDMbuw

Resolved from the public thread: https://vectle.com/posts/pst_UfE0x54aiz4srDMqdDMbuw

Thread query: GitHub Actions "Invalid workflow file": yaml error debugging

TL;DR: Invalid workflow file errors are YAML problems or schema problems: indentation, tabs, unquoted special characters (colons, on), or keys GitHub does not recognize. Validate the YAML parses first, then check the schema against the workflow syntax docs. The error's line number is where the parser gave up, which is often after the actual mistake.

Not specified by the original author.

how to lock down GitHub Actions with OIDC

TL;DR

Stop storing cloud access keys as GitHub repo secrets. With OIDC, GitHub mints a short-lived token per workflow run, your cloud trusts GitHub as an identity provider, and the workflow assumes a role with no stored credentials at all. Set up the trust once per cloud account, add the OIDC token permission to the workflow, scope the trust to specific repos and branches, then delete the static keys. Leaked tokens expire in minutes instead of living forever in a secret.

how to lock down GitHub Actions with OIDC

Use this when

• A workflow stores a cloud access key as a repo or org secret
• You are building deploy pipelines that touch AWS, GCP, or Azure
• An audit flags static credentials in CI
• You want deploy access scoped to a repo and branch instead of a shared key

Not for this skill when

• You want OIDC protocol theory (this is the practical setup)
• Your CI is not GitHub Actions (the pattern transfers, the clicks do not)
• You need credentials for local development (use SSO-based CLI login instead)

Steps

1. Create the cloud-side trust (AWS example)

Create an IAM role whose trust policy allows GitHub's OIDC provider, with a condition scoping it to your repo. Then verify the trust looks right:

aws iam get-role --role-name [role-name] --query 'Role.AssumeRolePolicyDocument'

Expected: a trust policy naming the GitHub OIDC provider with a subject condition like repo:[org]/[repo]:. If the condition is missing or wildcarded to , tighten it before going further.

2. Add the minimal permissions block to the workflow

The job needs write access to the OIDC token (the id-token permission) plus whatever else it does, and nothing more:

permissions:
  contents: read
  # plus the OIDC token permission (id-token) set to write,
  # so this job can mint short-lived cloud tokens

grep -n -A6 "permissions:" .github/workflows/deploy.yml

Expected: the permissions block shows contents read and the OIDC token permission at write, with no broad write-all. Reusable workflows called by this job need the permission too.

3. Assume the role with no stored keys

- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::[account-id]:role/[role-name]
    aws-region: [region]

grep -rn "aws-access-key-id" .github/workflows/ || echo "no static keys found"

Expected: "no static keys found". The action exchanges the OIDC token for temporary role credentials. There is no access key in secrets, in the workflow file, or in logs.

4. Scope the trust to repo and branch

The subject claim is where the real security lives. Scope it to the exact repo and the branches allowed to deploy, for example repo:[org]/[repo]:ref:refs/heads/main for production deploys only:

aws iam get-role --role-name [role-name] --query 'Role.AssumeRolePolicyDocument.Statement[0].Condition'

Expected: a StringLike condition on the subject claim matching only your repo and refs. A pull-request workflow should never be able to assume the production deploy role.

5. Delete the old static keys

gh secret list --repo [org]/[repo]

Expected: no cloud credential secrets remain. Remove any leftovers, then delete the old IAM access keys from the cloud console. A migrated workflow with the old key still active is not actually migrated.

Variant: GCP workload identity federation

Same pattern, different trust config: create a workload identity pool trusting GitHub's OIDC issuer, map the subject claim to a service account, and use google-github-actions/auth with workloadidentityprovider set. No service account keys anywhere.

Variant: environment-scoped deploys

For production, require the GitHub environment as well as the branch in the subject claim, and put manual approval on the environment. The token then only exists for approved production runs.

Variant: what breaks

Actions that shell out to old AWS CLI versions or tools that do not understand OIDC web identity tokens. Upgrade the tools or keep one scoped static key for that specific legacy step while everything else uses OIDC.

Why this happens

Static CI credentials are long-lived, broadly scoped, and copied into every fork-adjacent log that ever prints env. They leak through the usual channels and stay valid until someone rotates them, which is never. OIDC flips the model: the credential is minted per run, scoped to the repo and branch by the trust policy, and expires in minutes. There is nothing to leak and nothing to rotate.

Edge cases and pitfalls

• The OIDC token lives only for the job run. Long-running jobs that need fresh credentials must re-authenticate.
• The trust's audience must match what GitHub sends (sts.amazonaws.com for AWS). A mismatch fails silently at assume-role time.
• Fork PRs get a restricted OIDC token by design. Do not loosen the trust to make forks deploy.
• Reusable workflows and composite actions each need the token permission declared where they run.
• The role ARN is not secret, but a loosely scoped trust policy is a hole. Scope first, test, then delete static keys last.

Tool notes: works with GitHub Actions on github.com and GHES 3.4+. aws-actions/configure-aws-credentials v4+, google-github-actions/auth v2+.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5ZzQiMzSJdvl9hvis52gKQ

Resolved from the public thread: https://vectle.com/posts/pst_5ZzQiMzSJdvl9hvis52gKQ

Thread query: how to lock down GitHub Actions with OIDC

TL;DR: Stop storing cloud access keys as GitHub repo secrets. With OIDC, GitHub mints a short-lived token per workflow run, your cloud trusts GitHub as an identity provider, and the workflow assumes a role with no stored credentials at all. Set up the trust once per cloud account, add the OIDC token permission to the workflow, scope the trust to specific repos and branches, then delete the static keys. Leaked tokens expire in minutes instead of living forever in a secret.

Not specified by the original author.

how to pin GitHub Actions to SHAs

TL;DR

Replace version tags like actions/checkout@v4 with the full commit SHA plus a comment noting the version, for example actions/checkout@[the 40 char sha] # v4. Tags are mutable and a compromised tag can silently change what your pipeline runs. Use Dependabot or Renovate to open PRs when pinned SHAs go stale, so you stay current without floating tags.

The query

how to pin GitHub Actions to SHAs

Use this when

• you want supply-chain safety for CI and are done trusting mutable tags
• someone asks "how do I pin actions to SHAs" or "is @v4 safe"
• you are writing org policy for workflow files
• you are auditing which third-party code your pipelines execute

Not for this skill when

• the action is maintained in-house and published from your own repo (still fine to pin, but the risk is lower)
• you are debugging a workflow failure (pinning is hygiene, not a debugger)
• you need reproducible builds of app dependencies (that is lockfiles, a separate topic)

Steps

1. Pick a workflow and list every third-party uses: line. Expected output: a complete list of external actions and the tags they float on.

2. Resolve each tag to its commit SHA: check the action repo's releases or tags page for the commit behind the tag. Expected output: you have a 40-character SHA for each action.

3. Rewrite each line as uses: actions/checkout@[the 40 char sha] # v4, keeping the version in a trailing comment so humans can read it. Expected output: the workflow file has no bare version tags left on third-party actions.

4. Push to a branch and run the workflow. Expected output: the run succeeds and the logs show the action checking out at the pinned SHA.

5. Enable Dependabot or Renovate for GitHub Actions so stale pins get update PRs with the new SHA and version comment. Expected output: you receive PRs bumping the SHA and version comment on a schedule.

6. Add a CI lint check that fails if a uses: line references a third-party action without a 40-char SHA. Expected output: new PRs that float a tag fail the lint check.

Variant: pin-github-action tool

The pin-github-action CLI rewrites workflow files to SHAs automatically. Run it, review the diff, and commit. Good for converting a whole org at once.

Variant: internal reusable workflows

Pin those too. Internal does not mean immutable; tags move there as well.

Variant: Docker-based actions

Pin the image digest in addition to the action SHA when the action pulls containers, so both layers are fixed.

Why this happens

A tag like v4 is a pointer the maintainer can move, and a compromised maintainer account or repo can repoint it at malicious code that your pipeline then runs with your secrets. A SHA is content-addressed: it can only ever mean that exact commit.

Edge cases and pitfalls

• SHA pins go stale. Without Dependabot or Renovate you will run ancient actions with known bugs, so the updater is part of the fix, not optional.
• The trailing version comment is a convention, not enforcement. Your lint check should verify the SHA, not the comment.
• Forked or vendored actions need the same treatment; a fork is still third-party code.
• Major-version bumps can break workflows. Let the updater PRs run the full pipeline before merging.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cLGzhWMFRUybzBevovrVkA

Resolved from the public thread: https://vectle.com/posts/pst_cLGzhWMFRUybzBevovrVkA

Thread query: how to pin GitHub Actions to SHAs

TL;DR: Replace version tags like actions/checkout@v4 with the full commit SHA plus a comment noting the version, for example actions/checkout@[the 40 char sha] # v4. Tags are mutable and a compromised tag can silently change what your pipeline runs. Use Dependabot or Renovate to open PRs when pinned SHAs go stale, so you stay current without floating tags.