3 ms·
This is always the top comment in these kinds of threads, and I see this as an indication that the current state of CI/CD is pathetically propriety. It’s like
by jiggawatts 1y ago
This is always the top comment in these kinds of threads, and I see this as an indication that the current state of CI/CD is pathetically propriety.
It’s like the dark times before free and open source compilers.
When are we going to push back and say enough is enough!?
CI/CD desperately needs something akin to Kubernetes to claw back our control and ability to work locally.
Personally, I’m fed up with pipeline development inner loops that involve a Git commit, push, and waiting around for five minutes with no debugger, no variable inspector, and dumping things to console logs like I’m writing C in the 1980s.
You and I shouldn’t be reinventing these wheels while standing inside the tyre shop.
- rsanheim 1y agoWe've had open source CI. We still have it. I remember ye olde days of Hudson, before it was renamed Jenkins. Lotsa orgs still use Jenkins all over the place, it just doesn't get much press. It predates GHA, Circle, and many of the popular cloud offerings. Turns out CI/CD is not an easy problem. I built a short-lived CI product before containers were really much of a thing ...you can guess how well that went. Also, I'll take _any_ CI solution, closed or open, that tries to be the _opposite_ of the complexity borg that is k8s.
- nitwit005 1y agoHaving a container makes debugging possible, but it's still generally going to be an unfriendly experience, compared to a script you can just run and debug immediately. It's inevitable that things will be more difficult to debug once you're using a third party asynchronous tool as part of the flow.