This project may be able to help you out: https://github.com/nektos/act/ (it provides a way to run GitHub actions locally)

I've tried to get `act` to work several times over the past few months, and never managed to get even a basic workflow to run locally. It kept giving cryptic errors that I had to dig into their code to figure out (e.g. requiring a GitHub Personal Access Token despite not mentioning it in the docs). It gave me the impression that it was far from functional, for now.

I eventually gave up and have been running Actions on GitHub from a branch, merging into the main one once it works.

How come Github doesn't have this? Just lemme run it locally. I've wasted so much time debugging my workflows... It's such a obvious miss.

Amazing that somebody developed that for Microsoft.

they probably developed it for themselves.

I use this action* to effectively put a 'breakpoint' in a job that lets you SSH in and inspect the env vars, files, refine your shell script code, etc. Cuts way down on the number of CI run/tweak/repeat cycles.

* https://github.com/marketplace/actions/debugging-with-tmate

I do the same. Dozens of commits to get GH Actions working correctly.

I feel far better hearing a few people say they do it the same.

It felt so wrong and amateur and kind of embarrassing.

It doesn't help the yaml ui/ux is awful.

   - if ${{ github.event_name == 'why do you think this is acceptable?" }}
      run:|
         echo "I need programmatic CI no matter how much you think I don't"

Just let us write our entire pipelines in typescript. People are already using Actions for bitcoin mining, hosting porn, or whatever - if I can do arbitrary shell stuff you're not making my life easier by putting it behind a yaml DSL pretending to be "no code."

If it were just typescript with a reasonable library we could run and debug it locally without jumping through hoops.

/rant

I don't get it how Python exists. Even with the best IDE support writing YAML is a misery.

I write Python for years (including messing code) and never feel the pain I found when I edit an even a slightly complicated YAML file.

The issue is not really the significant indentation of YAML, it is more of the ambiguity of the syntax plus the fact that YAML is a serialization format so it doesn't have many ways to reduce repetition. Now those issues coupled with the significant indentation makes YAML a mess, but those issues doesn't exist in Python.

What CI/CD system other than Jenkins uses a configuration format that isn't YAML?

Team City. But Jenkins is still king.

I think one either loves it or hates it..

Buildbot

yup and with proper IDE support as well

I've been making a custom build image in large part because of this. Local testing with Docker isn't the most fun, I have to manually manage the environment variables I pass on the command line, but it's way better than commit then wait for Docker to schedule.

Once it's working locally I push up and it's usually only a commit or two away from working.

Countless commits with the same message "flailing" until it works. Typically takes about 30.

I suppose we all just brute force it.

For my private projects, I just make it rain with minor incremental improvements, and once it is green, I rebase and squash.

For shared/OS projects, I'd rather fork it and then work on my fork, so I don't trigger emails or other webhooks.

Pushing countless commits is fine as long as you are doing it in your own branch.

It's not very cost-effective though.

If CI cost is a problem then test everything locally before pushing.

…but the point is they’re testing CI itself, which doesn’t exist locally.

Sourcehut at least lets you submit build manifests to builds.sr.ht without having to push, push, push.

if I remember correctly CircleCI is the only CI-provider that would let you run their pipelines/actions locally in a Docker container. That worked really well for me, quick feedback loop without creating commits.

Drone CI, too - you can "drone exec" a pipeline and it'll work the same way as on the CI server. It's a great feature to have.

I've resorted to running my own local copy of GL (and, of course, its runner) for troubleshooting build complexity, since their runner pool has been so indescribably bad of late: https://status.gitlab.com/pages/history/5b36dc6502d06804c083...

I agree with the other comments that CircleCI is my high-bar for "how can a sane person run the build locally?" because I also agree with the other comments that "act" is handy, but only for the most trivial of hello-world builds, and `gitlab-runner exec` is a cruel joke

Gitlab also offers this feature [0] [1]

[0] - https://docs.gitlab.com/ee/ci/quick_start/#ensure-you-have-r...

[1] - https://medium.com/@umutuluer/how-to-test-gitlab-ci-locally-...

Codeship does this too with their `jet` command.

Haven't found a better way than `./ci.sh` and do as much work as possible to keep github actions/travis/jenkins/whatever from requiring something different than running locally.

It's sisyphean.

In our stack we use a custom CI runner and that's the image we give to gitlab-ci, so it's easy to just test locally. Not sure what the story is with GHA, but generally I try to make sure everything fits into one script so I can just test that. A more fun/hacky option is opening a reverse shell on the CI box. I was even able to get it working through ngrok to my local machine.

Maybe you will be interested in https://earthly.dev/

Cannot this be used for running it with a local change? If no,t what's the point? (Not complaining to you but seriously.)