Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Pain That Is GitHub Actions

feldera.com

Post reply on HN
Print view View original

111–120 of 584 posts

Re: The Pain That Is GitHub Actions

#111

Post by ehansdais »

deng wrote: post #86

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…

After years of trial and error our team has come to the same conclusion. I know some people might consider this insanity, but we actually run all of our scripts as a separate C# CLI application (The main application is a C# web server). Effectively no bash scripts, except as the entry point here and there. The build step and passing the executable around is a small price to pay for the gain in static type checking, being able to pull in libraries as needed, and knowing that our CI is not going to down because someone made a dumb typo somewhere.

The other thing I would add is consider passing in all environment variables as args. This makes it easy to see what dependencies the script actually needs, and has the bonus of being even more portable.

Re: The Pain That Is GitHub Actions

#112

Post by JanMa »

deng wrote: post #86

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…

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.

Re: The Pain That Is GitHub Actions

#113

Post by raffraffraff »

HdS84 wrote: post #80
yoyohello13 wrote: post #28

Earlier quoted context omitted.

Glad I’m not the only one. GitLab runners just make sense to me. A container you run scripts in. I have some GitHub actions for some side projects and it just seems so much more confusing to setup for some reason.

There are lots of problems. Actions try to abstract the script away and give you a consistent experience and, must crucially, allow sharing. Because gitlab has no real way to share actions or workflows (I can do yaml include, but come on that sucks even harder than actions) you are constantly reinventing the wheel. That's ok if all you do is " build folder" but if you need caching, reporting of issues, code coverage…

I haven't looked too much into how sharing workflows works, but isn't the use of shared GitHub workflows (from outside your org) a little dangerous? I get it, we use other people's code all the time. Some we trust more (ISO of a Linux OS with SHA) and others we trust a little less even if it comes from a verified source with GPG, because we know that supply chain attacks can happen.

Every time someone introduced a new way to use someone else's shared magic I feel nervous about using it. Like GitHub Actions. Perhaps it's time for me to dig into them a bit more and try to understand if/how they're safe to use. But I seem to remember just a few days ago someone mentioning a GitHub action getting hijacked?

Re: The Pain That Is GitHub Actions

#114

Post by cesnja »

deng wrote: post #86

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…

You can build the first pipeline with oneliners, but as long as you want to keep optimizing the pipelines, the yaml code will keep piling up with CI vendor's specific approaches to job selection, env variable delivery, caching, output sharing between jobs and so on.

Re: The Pain That Is GitHub Actions

#115

Post by flanked-evergl »

tobinfekkes wrote: post #81

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…

Software engineer thrives on iteration speed. Things have to change, if your pipeline is difficult to change it will cost you.

Re: The Pain That Is GitHub Actions

#116

Post by tobinfekkes »

IshKebab wrote: post #91
tobinfekkes wrote: post #81

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!

I guess it's possible. But I also don't really have anything to ignore....? I genuinely never have an issue; it builds code, every time.

I commit code, push it, wait 45 seconds, it syncs to AWS, then all my sites periodically ping the S3 bucket for any changes, and download any new items. It's one of the most reliable pieces of my entire stack. It's comically consistent, compared to anything I try building for a mobile app or pushing to a mobile app store.

I look forward to opening my IDE to push code to the Actions for my web app, and I dread the build pipeline for a mobile app.

Re: The Pain That Is GitHub Actions

#117

Post by globular-toast »

yoyohello13 wrote: post #28
silisili wrote: post #16

I worked at companies using Gitlab for a decade, and got familiar with runners. Recently switched to a company using Github, and assumed I'd be blown away by their offering because of their size. Well, I was, but not in the way I'd hoped. They're absolutely awful in comparison, and I'm beyond confused how it got to that state. If I were running a company and had to choose between the two, I'd pick Gitlab every time j…

Glad I’m not the only one. GitLab runners just make sense to me. A container you run scripts in. I have some GitHub actions for some side projects and it just seems so much more confusing to setup for some reason.

Same. I'd been using Gitlab for a few years when Actions came out. Looked at it and thought, wow that's weird, but gave it the benefit of the doubt as it's just different, surely it would make sense eventually. Well no, it doesn't make sense, and seeing all the shocked Pikachu at the action compromise the other day was amusing.

Re: The Pain That Is GitHub Actions

#118

Post by baq »

ehansdais wrote: post #111
deng wrote: post #86

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…

After years of trial and error our team has come to the same conclusion. I know some people might consider this insanity, but we actually run all of our scripts as a separate C# CLI application (The main application is a C# web server). Effectively no bash scripts, except as the entry point here and there. The build step and passing the executable around is a small price to pay for the gain in static type checking, b…

> I know some people might consider this insanity

Some people here still can’t believe YAML is used for not only configuration, but complex code like optimized CI pipelines. This is insane. You’re actually introducing much needed sanity into the process by admitting that a real programming language is the tool to use here.

I can’t imagine the cognitive dissonance Lisp folks have when dealing with this madness, not being one myself.

Re: The Pain That Is GitHub Actions

#119

Post by forrestthewoods »

deng wrote: post #86

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…

> pipelines can run locally on a developer machine as well (as much as possible at least)

Facts.

However I’ll go a step further and say “only implement your logic in a tool that has a debugger”.

YAML is the worse. But shell scripts are second worst. Use a real language.

Re: The Pain That Is GitHub Actions

#120

Post by kroolik »

HdS84 wrote: post #80
yoyohello13 wrote: post #28

Earlier quoted context omitted.

Glad I’m not the only one. GitLab runners just make sense to me. A container you run scripts in. I have some GitHub actions for some side projects and it just seems so much more confusing to setup for some reason.

There are lots of problems. Actions try to abstract the script away and give you a consistent experience and, must crucially, allow sharing. Because gitlab has no real way to share actions or workflows (I can do yaml include, but come on that sucks even harder than actions) you are constantly reinventing the wheel. That's ok if all you do is " build folder" but if you need caching, reporting of issues, code coverage…

You can apply dynamic env to other jobs by exporting an env file as a dotenv artifact. So first job creates a dotenv file and export it as artifact. Second depends on the first so it can consume the artifact. https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifacts...
Post reply on HN