151–160 of 584 posts
Nothing beats having a single script to bootstrap and run the whole pipeline e.g. `make ci`.
There is one thing that I haven’t seen mentioned: worst possible feedback loop. I’ve noticed this phenomenon few times already, and I think there’s nothing worse than having a 30-60s feedback loop. The one that keeps you glued to the screen but otherwise is completely nonproductive. I tried for many moons to replicate GHA environment on local and it’s impossible in my context. So every change is like „push, wait for…
Feel this pain so much. If you are debugging Github Action container builds, and each takes over ~40 minutes to build.. you can burn through a whole work day only testing six or seven changes. There has to be a better way. How has nobody figured this out?
Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…
Can you explain YAML? I've found declarative pipelines with it have been... fine?
However, CI is not "configured", it is coded. It is simply the wrong tool. YAML was continuously extended to deal with that, so it developed into much more than just "markup", but it grew into this terrible chimera. Once you start using advanced features in GitLab's YAML like anchors and references to avoid writing the same stuff again and again, you'll notice that the whole tooling around YAML is simply not there. How does the resulting YAML look like? How do you run this stuff locally? How do you debug this? Just don't go there.
You will not be able to avoid YAML completely, obviously, but use it the way it was originally intended to.
This is the joy of HN, for me, at least. I'm genuinely fascinated to read that both GitHub Actions and DevOps are (apparently) so universally hated. I've been using both for many years, with barely a hiccup, and I actually really enjoy and value what they do. It would never have dawned on me, outside this thread, to think that so many people dislike it. Nice to see a different perspective! Are the Actions a little cu…
Sounds like you have the same pain points as everyone else; you're just more willing to ignore them. I am with the author - we can do better than the status quo!
You notice a deprecation warning in the logs, or an email from GitHub and you make a 1 line commit to bump the node version. Easy.
Sure you can make typos that you don’t spot until you’ve pushed and the action doesn’t run, but I quickly learned to stop being lazy and actually think about what I’m writing, and get someone else to do an actual review (not just scroll down and up and give it a LGTM).
My experience is same as the commenter above, it’s relatively set and forget. A few minutes setup work for hours and hours of benefit over years of builds.
I hope Actions stays bad tho. We need more folks to get off proprietary code forges for their open source projects—& a better CI + a better review model (PRs are awful) are 2 very low-hanging fruit that would entice folks off of the platform not for the philosophical reasons such as not supporting US corporations or endangering contributor privacy by making them agree to Microsoft’s ToS, but for technical superiority on the platform itself.
Earlier quoted context omitted.
This is where I was going to say something about dagger, but it seems it turned into AI crud. Let me at least recommend depot.dev for having absurdly fast runners.
can you give more feedback about dagger? what is good/not good about it? I was going to start looking into it
Earlier quoted context omitted.
Whenever possible I now just use GitHub actions as a thin wrapper around a Makefile and this has improved my experience with it a lot. The Makefile takes care of installing all necessary dependencies and runs the relevant build/Test commands. This also enables me to test that stuff locally again without the long feedback loop mentioned in other comments in this thread.
mise ( https://mise.jdx.dev/ ) and dagger ( https://github.com/dagger/dagger ) seem like nice candidates too! Mise can install all your deps, and run tasks
Literally from comment at the root of this thread.
Most of the time, I'm just running dotnet build to a zip file and s3 bucket. Then, some code or script picks it up on the other side. Things get much trickier when you're using multiple services, languages, runtimes, database technologies, etc.
GitHub Actions is just a way to build a remote single point of failure into your pipeline. I don't get why people do this. If GitHub goes down, or has problems for whatever reasons it can interfere with your deliverables to customers. I learned early in my career not to trust 3rd parties as any part of any mission critical process. 3rd parties will always fail you, it's just a matter of time.
With widespread dependencies like AWS or Github, if they go down.. you benefit from everybody else also going down. Downtime of that kind means a lot of media coverage and an easier/more understanding conversation with your affected customers. The worst kind of downtime is when you go down but nobody else has.
Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…
Can you explain YAML? I've found declarative pipelines with it have been... fine?
YAML is great for the happy-flow where everything works. It's absolutely terrible for any other flow.