Discussion on "GitHub Actions I Set Up on Every Project"

Madhav Bhasin · 2026-09-21T03:22:03.678Z

Most engineers using GitHub Actions daily know how to write a basic workflow — checkout, install dependencies, run tests, deploy. That covers 80% of what they need. The other 20% is a set of features

Setting concurrency groups with cancel-in-progress on pull requests saves a lot of runner time. It prevents older commits from queuing up duplicate test runs when developers push rapid fixup commits.

Exactly — the queue buildup from rapid fixup commits is the most visible pain point that concurrency groups solve. The cancel-in-progress: false distinction for deploys is worth keeping in mind too, where you want queuing rather than cancellation.

The reusable workflows section is a great addition. One thing I’ve found useful is treating the workflow interface almost like an API: keep inputs and outputs explicit, document the expected permissions, and avoid making the reusable workflow depend on repository-specific assumptions. That makes it much easier to reuse the same workflow across projects without creating hidden coupling. The combination of reusable workflows, caching, and concurrency can make a surprisingly big difference as a project grows.

"Treat the workflow interface like an API" is the right mental model and the post doesn't say it that clearly. Explicit inputs and outputs, documented permissions, no repository-specific assumptions baked in — those are the constraints that make a reusable workflow actually reusable rather than just shared. The hidden coupling problem is real and usually shows up the second time you try to use the workflow somewhere new.

The reusable-workflow section is missing one option worth naming: secrets: inherit instead of listing each secret name explicitly. Handy once a caller needs a dozen secrets, but it also means every secret available to the caller becomes available to the callee, which is a real governance tradeoff once a shared workflow lives in a repo with anything sensitive in it. Worth deciding per-repo rather than defaulting to it.

Good addition — secrets: inherit is the obvious convenience solution that creates a non-obvious governance problem. Once a shared workflow lives in a central repo, inheriting everything means the callee gets access to secrets it doesn't need, across every repo that calls it. Fine for a small team with a single org repo. Worth a deliberate decision rather than a default once you're managing secrets across multiple projects or teams.

Search Hashnode

GitHub Actions I Set Up on Every Project

Responses(6)