Am I missing something obvious or do these kinds of systems lack a good story for testing?
With Travis and now GH Actions I find the fastest way to develop is to just push countless commits and incrementally develop my work flow in a live-ish way while asking peers to ignore the email spam on failures.
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.
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.
- 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.
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.
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.
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.
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
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.
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.
With Travis and now GH Actions I find the fastest way to develop is to just push countless commits and incrementally develop my work flow in a live-ish way while asking peers to ignore the email spam on failures.