265
"GitHub CI is easy", he said. "It's just bash ", he said.
(programming.dev)
Until he actually had to use it.
Took 2 hours of reading through examples just to deploy the site.
Turns out, it is hard to do even just the bash stuff when you can't see the container.
Time for the yearly barrage of "Setup CI"..."Fix CI" commits.
That is my experience with basically every CI service out there.
Normally, you don't want to commit code unless it's been at least minimally tested, and preferably more than that.
All the CI's, however, force a workflow where you can only test it by committing the code and seeing if it works. I'm not sure how to fix that, but I see the problem.
Here's my hot tip! (ok maybe luke warm)
Write as much of your CICD in a scripting language like bash/python/whatever. You'll be able to test it locally and then the testing phase of your CICD will just be setting up the environment so it has the right git branches coined, permissions, etc.
You won't need to do 30 commits now, only like 7! And you'll cry for only like 20 minutes instead of a whole afternoon!
We have all of our build and CI in
makeso, theoretically, all the CI system needs to do is run a single command. Then I try to run the command on a CI server, it is missing an OS package (and their package manager version is a major version behind so I need to download a pre-built binary from the project site). Then the tests get kill for using too much memory. Then, after I reduce resource limits, the tests time out…I am grateful that we use CircleCI as our SaaS CICD and they let me SSH on to a test container so I can see what is going on.