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

221–230 of 584 posts

Re: The Pain That Is GitHub Actions

#221

Post by ManBeardPc »

mab122 wrote: post #198
ManBeardPc wrote: post #177

CI environments like Gitlab or Github are my nemesis. Another technology that everyone swears is absolute necessary but somehow makes everything more complicated. The provided environments in companies so far are hell 100% the time and managed by inexperienced personnel with zero or little programming experience. * Barely reproducible because things like the settings of the server (environment variables are just one…

but then, but then your corporate provided laptop with 8GB RAM and 128GB with locked down Windows Entprise™® may need 1000th of security policy exceptions and won't even fit all dependencies on its disk. Not to mention that it would be building for like 10h. Think of the shareholders! The corporation would have to buy actually usable hardware for it's workers! Think of the cost! /j For real tho, not every project can…

True, many of the problems are not solvable by technology alone. Hostile environments can be created for every approach if the corporation doesn't know/care how to do it properly. Luckily I'm blessed that my employers mostly give me admin permissions on my machine and provide decent hardware. The hardware my customers force me to use though... lets say at least I have some free time for other things.

Laptops are a lot cheaper then the cloud bills I have seen so far. Penny pinching every tiny thing for <100$/€, but cloud seems to run on an infinite magic budget...

Re: The Pain That Is GitHub Actions

#222

Post by mwenge »

JanMa wrote: post #112
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.

Do you have a public example of this? I'd love to see how to do this with Github Actions.

Re: The Pain That Is GitHub Actions

#223

Post by tasuki »

baq wrote: post #129
gazereth wrote: post #124

Earlier quoted context omitted.

Pinning dependencies is trading one problem for another. Yes, your builds will work as expected for a stretch of time, but that period will come to an end, eventually. Then one day you will be forced to update those pinned dependencies and you might find yourself having to upgrade through several major versions, with breaking changes and knock-on effects to the rest of your pipelines. Allowing rolling updates to depe…

Not pinning dependencies is an existential risk to the business. Yes it’s a tradeoff, you must assign a probability of any dependency being hijacked in your timeframe yourself, but it is not zero.

I don't think others were necessarily talking about "business".

Though, yes, I prefer pinning dependencies for my personal projects. I don't see why things should break when I explicitly keep them the same.

Re: The Pain That Is GitHub Actions

#224

Post by cnotv »

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…

Once, a reliable and wise colleague told me "Use in CI what you use locally" and that has been the best devop advice that never failed me to save my time.

The second one has been, from someone else: if you can use anything else than bash, do that.

Re: The Pain That Is GitHub Actions

#225

Post by agumonkey »

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…

seconded, it was great to leverage hosted cicd at work, until we realized that local testing would now be handled differently..

as always, enough decoupling is useful

Re: The Pain That Is GitHub Actions

#226

Post by motorest »

deng wrote: post #153
qweiopqweiop wrote: post #128

Earlier quoted context omitted.

Can you explain YAML? I've found declarative pipelines with it have been... fine?

YAML is fine for what it is: a markup language. I have no problem with it being used in simple configuration files, for instance. 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 r…

> However, CI is not "configured", it is coded.

No, it really isn't. I'll clarify why.

Pretty much all pipeline services share the same architecture pattern:

* A pipeline run is comprised of one or more build jobs,

* Pipeline runs are triggered by external events

* Build jobs have contexts and can output artifacts,

* Build jobs are grouped into stages,

* Stages are organized as a directed graph,

* Transitions between stages in the directed graph is ruled by a set of rules, some supported by default (i.e., if a job fails then the stage fails) complemented by custom rules (manual or automatic approvals, API tests, baking periods, etc).

This is the textbook scenario ideal for DSLs. You already are bound to an architecture pattern, this there is no point of reinventing the wheel each time. Just specify your stages and which jobs run as part of each stage, manage artifacts and promotion logic, and you're done.

You do not need to take my word for it. Take a look at GitLab CICD for a pipeline with build, test, and delivery stage. See what a mess you will put together if you support the same feature set with whatever scripting language you choose. There is no discussion or debate.

Re: The Pain That Is GitHub Actions

#227

Post by [deleted] »

dijit wrote: post #97
hn_throwaway_99 wrote: post #19

> A few days ago, someone compromised a popular GitHub Action. The response? "Just pin your dependencies to a hash." Except as comments also pointed out, almost no one does. I used GitHub actions when building a fin services app, so I absolutely used the hash to specify Action dependencies. I agree that this should be the default, or even the required, way to pull in Action dependencies, but saying "almost no one doe…

I think the HN community at large had a bit of a learning experience a couple of days ago. "Defaults matter" is a common phrase, but equally true is: "the pattern everyone recommends including example documentation matters". It is fair to criticise the usage of GH Actions, just like it's fair to criticise common usage patterns of MySQL that eat your data - even if smarter individuals (who learn from deep understandin…

[deleted]

Re: The Pain That Is GitHub Actions

#228

Post by mst »

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…

Honestly, "using the same language as the application" is often a solid choice no matter what the application is written in. (and I suspect that for any given language somebody might propose as an exception to that rule, there's more than one team out there doing it anyway and finding it works better for them than everything else they've tried)

Re: The Pain That Is GitHub Actions

#229

Post by mst »

motorest wrote: post #217
baq wrote: post #118

Earlier quoted context omitted.

> 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 be…

> Some people here still can’t believe YAML is used for not only configuration, but complex code like optimized CI pipelines. I've been using YAML for ages and I never had any issue with it. What do you think is wrong with YAML?

Turing complete YAML ends up being an app specific terrible programming language.

Many of us would rather use a less terrible programming language instead.

Re: The Pain That Is GitHub Actions

#230

Post by motorest »

LeonM wrote: post #193
deng wrote: post #153

Earlier quoted context omitted.

YAML is fine for what it is: a markup language. I have no problem with it being used in simple configuration files, for instance. 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 r…

> CI is not "configured", it is coded. Finally! I was always struggling to explain to others why YAML is OK-ish as a language, but then never seems to work well for the things people tried doing with it. Especially stuff that needs to run commands, such as CI. > How does the resulting YAML look like? How do you run this stuff locally? How do you debug this? Just don't go there. Agreed. GitHub actions, or any remote C…

> Especially stuff that needs to run commands, such as CI.

I don't understand what problem you could possibly be experiencing. What exactly do you find hard about running commands in, say, GitLab CICD?

Post reply on HN