The day I forget to run tests before merging I'll set up CI/CD (hasn't happened before, unlikely, but not impossible).
My build process is gp && gp heroku main. Minor commits straight to main. Major features get a branch. This is manual, simple and loveable. And involves zero all-nighters commit-spamming the .github directory :)
I mean, I agree it would be nice to be able to test actions locally (maybe there's a tool for this). But I keep my actions very simple, so it rarely takes me a lot of time to get them right. See https://github.com/nixpulvis/grapl/blob/master/.github/workf...
If you want more complex functionality, that's why I suggested improving your build system, so the actions themselves are pretty simple.
Where things get more frustrating for me is when you try using more advanced parts of actions like releases and artifacts which aren't as simple as running a script and checking it's output/exit code.
Just refreshed my memory by looking at mine. 103 lines. Just the glance brought back painful memories. The worst areas were:
- Installing ruby/bundler/gems/postgres/js libraries, dealing with versioning issues, and every few months have them suddenly stop working for some reason that had to be addressed in order to deploy.
- Installing capybara and headless chrome and running system tests (system tests can be flakey enough locally, let alone remotely).
- Minor issue of me developing on a mac, deploying to heroku, so linux on GHA needs a few more things installed than I'm used to, creating more work (not the end of the world, and good to learn, but slow when it's done via a yaml file that has to be committed and run for a few minutes just to see the error).
The day I forget to run tests before merging I'll set up CI/CD (hasn't happened before, unlikely, but not impossible).
My build process is gp && gp heroku main. Minor commits straight to main. Major features get a branch. This is manual, simple and loveable. And involves zero all-nighters commit-spamming the .github directory :)