101–110 of 238 posts
I want to be able to run my all of CI workflows on my local machine.
I agree with other commenters that most of what CI does should be abstracted out into scripts or other non-CI tools. Unfortunately it's not easy to do that for large pre-existing CI setups, especially if a different team is the one maintaining your CI workflows.
I couldn't agree more with the pain of debugging a GH Actions run. The /only/ tool you have is the ability to re-run with debug on. That's it. I have so many "trash" commits trying to fix or debug a pipeline and so much of it's just throwing stuff at the wall to see if it sticks. Very basic things, like having reusable logic, is needlessly complex or poorly documented. Once I figured out how to do it it was fairly ea…
We built Earthly [1] to tackle these two problems specifically. We're open-source (10k stars).
[1]: https://earthly.dev
There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…
Earlier quoted context omitted.
Good perspective. Unfortunately (1) is unavoidable when you're trying to automate GH itself (role assignments, tagging, etc.). But at this point, I would rather handle a lot of that manually than deal with GHA's awful debug loop. FWIW, there's nektos/act[^1], which aims to duplicate GHA behavior locally, but I haven't tried it yet. [^1]: https://github.com/nektos/act
> Unfortunately (1) is unavoidable when you're trying to automate GH itself (role assignments, tagging, etc.) Can't you just use the Github API for that? The script would be triggered by the YAML, but all logic is inside the script. But `act` is cool, I've used it for local debugging. Thing is its output is impossibly verbose, and they don't aim to support everything an action does (which is fine if you stick to (2))…
The main thing that you can't decouple from GHA is pushing and pulling intermediate artifacts, which for some build pipelines is going to be a pretty big chunk of the logic.
I couldn't agree more with the pain of debugging a GH Actions run. The /only/ tool you have is the ability to re-run with debug on. That's it. I have so many "trash" commits trying to fix or debug a pipeline and so much of it's just throwing stuff at the wall to see if it sticks. Very basic things, like having reusable logic, is needlessly complex or poorly documented. Once I figured out how to do it it was fairly ea…
If I'm fixing CI I always put it on a feature branch and do a squash merge once I'm done. Because it's never just one quick fix, it's always 3-10 commits.
The problem is GA also does not allow you to commit a new workflow in a branch. It must first exist on your primary branch and then you may tweak it in another.
There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…
I agree overall, but you oversimplify the issue a bit. > can I push this YAML complexity into a script? - what language is the script written in? - will developers use the same language for all those scripts? - does it need dependencies? - where are we going to host scripts used by multiple github actions? - if we ended up putting those scripts in repositories, how do we update the actions once we release new version…
There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…
I agree overall, but you oversimplify the issue a bit. > can I push this YAML complexity into a script? - what language is the script written in? - will developers use the same language for all those scripts? - does it need dependencies? - where are we going to host scripts used by multiple github actions? - if we ended up putting those scripts in repositories, how do we update the actions once we release new version…
I think the point about maintenance cost is valid, but the thesis of the comment that you are responding to is that the prebuilt actions are a complexity trap.
As a result, few GitHub workflows benefit from the immutability or reproducibility guarantees that can be provided by containers, and most workflows I interact with spend more than half their time running ridiculous installer scripts.