About the GitHub Actions Workflow Builder
GitHub Actions workflows fail in a small number of recurring ways: a trigger that does not fire when expected, a cache that never hits, and permissions that are either too broad or missing entirely. This builder produces the workflow YAML with those parts already correct.
The security setting worth getting right on day one is the token permissions. The default GITHUB_TOKEN scope can be broader than a workflow needs, and a job that only reads code should declare read-only contents access explicitly. For anything that authenticates to a cloud provider, OIDC is now the correct approach — the workflow requests a short-lived token from the provider rather than holding a long-lived access key in repository secrets.
The trigger that surprises people is pull_request from a fork, which deliberately runs without access to secrets. pull_request_target does have that access, and running it against untrusted head code is a well-known route to leaking every secret in the repository.
Frequently asked questions
Why is my cache never hitting?
Almost always the key. A cache key must change when the dependencies change and stay stable otherwise, which usually means hashing the lockfile. A key with no hash never invalidates and serves stale dependencies; a key including the run number or a timestamp never matches. Use restore-keys as a prefix fallback so a partial hit still avoids a cold install.
What is the difference between pull_request and pull_request_target?
pull_request runs the workflow from the merge commit without repository secrets when the pull request comes from a fork. pull_request_target runs the workflow definition from the base branch with full secret access. Checking out and executing the pull request's code inside a pull_request_target job hands an attacker your secrets, so treat that combination as a vulnerability.
How do I stop redundant runs on rapid pushes?
Use a concurrency group keyed on the workflow and the ref, with cancel-in-progress enabled. Pushing three times in a minute then leaves only the newest run alive. Do not enable cancellation on deployment workflows, where a cancelled run can leave a partially applied change behind.
Should I use OIDC instead of storing cloud credentials?
Yes, wherever the provider supports it. OIDC exchanges a short-lived workflow identity token for temporary cloud credentials, so there is no long-lived key to leak or rotate, and the trust policy can be scoped to a specific repository and branch. Storing a permanent access key as a repository secret is now the fallback rather than the default.
Why does my job not run on a tag push?
Branch and tag filters are separate. A push trigger filtered by branches never matches a tag, no matter what the tag is called. Tags need an explicit tags filter. Related trap: a workflow using both a paths filter and a required status check will be skipped rather than run when nothing matches, and a skipped required check blocks the merge.