Live data from Hacker News

I'll think twice before using GitHub Actions again

ninkovic.dev

281–284 of 284 posts

Re: I'll think twice before using GitHub Actions again

#281
post #199

Earlier quoted context omitted.

If all your targets are .PHONY, you might as well just as bash (or your favourite shell) directly. Make targets look suspiciously like functions (or procedures), but they actually aren't.

I don't typically use .PHONY as my targets aren't the same name as files and performance isn't an issue. Here is an example of a "complex" Makefile I use to help manage Helm deployments ( https://github.com/peterwwillis/devops-infrastructure/blob/m... ). It uses canned recipes, functions (for loops), default targets, it includes targets and variables from other Makefiles, conditionally crafts argument lists, and more…

> I don't typically use .PHONY as my targets aren't the same name as files and performance isn't an issue.

They are still phony at heart in this case, even if you don't declare them .PHONY.

Make really wants to produce files; if your targets don't produce the files they are named for you are going to run into trouble (or have to be rather careful to avoid the sharp edges).

> They say "use the best tool for the job". As far as I've found, for a job like that, Make fits the best. If some day somebody completely re-writes all the functionality of Make in a less-obnoxious way, I'll use that.

You could try eg Shake (https://shakebuild.com/), but it requires some Haskell.

Re: I'll think twice before using GitHub Actions again

#282

Earlier quoted context omitted.

The reason it gets unbearably messy is that GitHub has constructed an ecosystem that encourages developers to write Turing complete imperative behavior into YAML without providing the same language constructs/tooling that a proper adult language provides to encourage code reuse and debugging. Without tooling like this any sufficiently complex system is guaranteed to evolve into a spaghetti mess, because no sane way e…

It's not just Github, Gitlab uses the same mess of YAML-programming with custom extensions. So do, I believe, many other systems. Ironically, Jenkins does this one correctly, they just give you a regular programming language. It's a shame there are so many other pitfalls, though.

Jenkins has almost the opposite problem: they give you the freedom to do everything, but point the gun right at your foot in the process of doing so

Re: I'll think twice before using GitHub Actions again

#283
post #103

Earlier quoted context omitted.

Best one I've used is the CI of sourcehut. So simple and so damn easy to set up.

You basically achieve the same result on github actions if you just ignore all of the github action yaml “magic” settings in the syntax and let your makefile/script do the logic which also makes it trivial to debug locally. But upvote because I do love sourcehut, it’s just so clean!

Yes, but with Sourcehut you can also SSH into the machine, making it trivial to debug.

Re: I'll think twice before using GitHub Actions again

#284

Why is this so difficult? 1. We apparently don’t even have a name for it. We just call it “CI” because that’s the adjacent practice. “Oh no the CI failed” 2. It’s conceptually a program that reports failure if whatever it is running fails and... that’s it 3. The long-standing principle of running “the CI” after merging is so backwards that that-other Hoare disparagingly called the correct way (guard “main” with a bot…

> We apparently don’t even have a name for it. We just call it “CI” because that’s the adjacent practice. “Oh no the CI failed”

Martin Fowler apparently calls this “continuous build” (the build itself without CI necessarily). And that’s better.

Post reply on HN