How do you avoid pushing over and over to debug GitHub Actions?

Try actionlint first. It can catch workflow problems through static analysis before you push, without having to run the whole pipeline. It won't prove that the commands or the runner environment work, but it's a quick check for the YAML and Actions-specific bits.

Act can run many GitHub Actions workflows locally, so it's useful when linting isn't enough. Don't assume a local pass guarantees a hosted runner will pass, though.

The runner images and available tools can differ. A full image can be very large, while smaller ones may need extra setup. The ACT environment variable can help you handle local-only setup when necessary, but that also means maintaining a difference between the two environments.

Keep the workflow boring. Put the build, test, or deployment logic in scripts you can run and test outside Actions, then have the workflow call those scripts. It's much faster to debug a script locally than an expanding block of inline workflow commands.

That doesn't eliminate every CI-only problem. Caching, artifacts, credentials, and runner configuration still live around the edges and can fail even when the script itself works.

Dagger is another option if you're willing to change how the pipeline is written. You can define CI steps for local execution and have Actions invoke them, which can also make the steps easier to test and move between providers.

It's not a drop-in fix for an existing workflow. Rewriting the pipeline may be more work than it's worth for a small project.

For a stubborn runner-specific issue, a temporary self-hosted runner gives you an environment you can inspect while debugging. That can help when the problem is in the runner setup rather than the build command itself. Clean it up once you're done.