We built the fastest CI in the world and it failed

Re:We built the fastest CI in the world and it failed by jnwatson on Tuesday September 12, 2023 @12:44PM (#37483973)

The only part of the Earthly pitch that resonated with me was the ability to run the CI locally. When debugging your CI, it is just faster to find problems when you can run on your own box.

I have a gnarly GitHub Actions script that took forever to get right because the debug cycle was 10 minutes long.

[ Parent | on HN ]

Re:We built the fastest CI in the world and it failed by fireflash38 on Tuesday September 12, 2023 @05:20PM (#37488571)

That's one of my biggest complaints about gitlab-ci. Theres basically no way to debug complex rules without just running it. They've got a way now to simulate for default branch, but that's like bare minimum necessary. No way to simulate based on vars or anything else. And no way to try locally, just gotta fucking send it live.

[ Parent | on HN ]

Re:We built the fastest CI in the world and it failed by ianwalter on Tuesday September 12, 2023 @05:24PM (#37488633)

I feel you on that one. There is also Act (https://github.com/nektos/act) and Dagger.io.

[ Parent | on HN ]

Re:We built the fastest CI in the world and it failed by jnwatson on Wednesday September 13, 2023 @04:15AM (#37493696)

I have a very complicated script and Act didn't work on it.

[ Parent | on HN ]

Re:We built the fastest CI in the world and it failed by smaudet on Tuesday September 12, 2023 @07:52PM (#37490315)

Yeah, the faster but is also a bit of a non-seller, they have to integrate the world/deal with bad build times that can't easily be parallelized (what if there are no modular dependencies, that your tool can understand?) except by tools that have nothing to do with their product.

But there have been many times when debugging a CI has been necessary, having to figure out what has gone wrong on a remote system is often an issue...ofc often the remote system is itself the problem...

[ Parent | on HN ]