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

541–550 of 584 posts

Re: The Pain That Is GitHub Actions

#541

Post by michaelmior »

tobinfekkes wrote: post #116
IshKebab wrote: post #91

Earlier quoted context omitted.

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

> I dread the build pipeline for a mobile app.

I would recommend looking at Fastlane[0] if you haven't already.

[0] https://github.com/fastlane/fastlane

Re: The Pain That Is GitHub Actions

#542

Post by marcosdumay »

badloginagain wrote: post #294
hi_hi wrote: post #234

Earlier quoted context omitted.

I came to the exact same conclusion accidentally in my first role as a Tech Lead a few years back. It was a large enterprise CMS project. The client had previously told everyone they couldn't automate deployments due to the hosted platform security, so deployments of code and configs were all done manually by a specific support engineer following a complex multistep run sheet. That was going about as well as you'd ex…

I hate the fact that CI peaked with Jenkins. I hate Jenkins, I hate Groovy, but for every company I've worked for there's been a 6-year-uptime Jenkins instance casually holding up the entire company. There's probably a lesson in there.

And the lesson is that you want a simple UI to launch shell scripts, maybe with complex triggers but probably not.

If you make anything more than that, your CI will fail. And you can do that with Jenkins, so the people that did it saw it work. (But Jenkins can do so much more, what is the entire reason so many people have nightmares just by hearing that name.)

Re: The Pain That Is GitHub Actions

#543

Post by mike_hearn »

dmuso wrote: post #506
mike_hearn wrote: post #499

Earlier quoted context omitted.

You just check the "delete files in checkout directory" box in the run screen. Are you thinking of something different? I've never had trouble doing a clean clone.

It’s been a while since I used it but I do remember that it doesn’t do a clean checkout and you can’t force it to. It leaves artifacts on the agent that can interfere with subsequent builds. I assume they do it for speed but it can affect reliability of builds

I don't know when you used it, but I've used it for years and it's always had that feature in every version I've used.

Re: The Pain That Is GitHub Actions

#544

Post by fireflash38 »

philistine wrote: post #324
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…

> * Avoid YAML as much as possible, period. Why does YAML have any traction when JSON is right there? I'm an idiot amateur and even I learned this lesson; my 1 MB YAML file full of data took 15 seconds to parse each time. I quickly learned to use JSON instead, takes half a second.

JSON is valid YAML.

YAML has comments. YAML is easily & trivially written by humans. JSON is easily & trivially written by code.

My lesson learned here? When generating YAML, instead generate JSON. If it's meant to be read and updated by humans, use something that can communicate to the humans (comments). And don't use YAML as a data interchange format.

Re: The Pain That Is GitHub Actions

#545

Post by squiggleblaz »

williamdclt wrote: post #529
sd9 wrote: post #519

Earlier quoted context omitted.

It’s the Gaelic spelling of “jail”. It hasn’t been used in mainstream British English since the 60s, outside of specific place names. Everyone in England says “jail” or “prison” today. It might be a bit different in Ireland.

Interesting! I assumed it was one of these loaned-but-misspelled words from French (geôle, pronounced johl with a soft j). I wonder if there’s a common etymology between the French and Gaelic

I think the PP was mistaken when they attributed it to Gaelic. It does indeed come from an antecedent of geôle; probably the spelling comes from the Norman form whereas the pronunciation comes from more widespread French forms. In any case, it isn't a case of "loaned-but-misspelled"; English got most of these words from times before French had standard spellings or - as in this case - pronunciations. And once they became part of English, they were subject to the future developments of English as English words, no longer French. It's like saying "geôle" is just misspelt Latin "caveola".

Re: The Pain That Is GitHub Actions

#546

Post by squiggleblaz »

mikepurvis wrote: post #389
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…

Strongly isolated systems like Nix and Bazel are amazing for giving no-fuss local reproducibility. Every CI "platform" is trying to seduce you into breaking things out into steps so that you can see their little visualizations of what's running in parallel or write special logic in groovy or JS to talk to an API and generate notifications or badges or whatever on the build page. All of that is cute, but it's ultimate…

Basically an online version of nix-output-monitor. Might be half an idea. But it doesn't get you 100%: you get CI, but not CD.

Re: The Pain That Is GitHub Actions

#547

Post by Tainnor »

0xbadcafebee wrote: post #380

I have used Travis, CircleCI, GitHub Actions, GitLab Pipelines, AWS CodeBuild/CodeDeploy, Bazel, Drone, GoCD, and Jenkins. And I have used GitLab, GitHub, and Bitbucket for hosting VCS files. (I'm the guy who manages this crap for a living, so I have used it all extensively, from startups to enterprises) GitHub Actions is the worst possible CI platform - except for all the others. Every single CI platform has weird l…

> GHA is great because of things like Dependabot [...] so you don't have to work hard to get anything advanced or specific to work.

That may have been true before GitHub decided that PRs can't access repository secrets anymore. Apparently now you can at least add these secrets to Dependabot too (which is still duplicate effort for setup and any time you rotate secrets), but at the time when the change was introduced there were only weird workarounds.

Re: The Pain That Is GitHub Actions

#548

Post by kbolino »

bastardoperator wrote: post #328
tom_ wrote: post #306

Earlier quoted context omitted.

Nothing significant on the face of it and I think that's pretty much exactly what's being suggested: don't have anything particularly interesting in the .yml file, just the bare minimum plus some small number of uncomplicated script invocations to install dependencies and actually do the build. (Iterating even on this stuff by waiting for the runner is still annoying though. You need to commit to the repo, push, and…

But GitHub recommends that, so if people don't follow best practices, and then complain when the docs are clear, who's at fault? The person writing against a system they don't understand because they haven't read the docs or the people who recommend what you're professing in the docs?

> But GitHub recommends that

Where?

Re: The Pain That Is GitHub Actions

#549

Post by bastardoperator »

kbolino wrote: post #548
bastardoperator wrote: post #328

Earlier quoted context omitted.

But GitHub recommends that, so if people don't follow best practices, and then complain when the docs are clear, who's at fault? The person writing against a system they don't understand because they haven't read the docs or the people who recommend what you're professing in the docs?

> But GitHub recommends that Where?

Here:

https://docs.github.com/en/actions/writing-workflows/choosin...

Re: The Pain That Is GitHub Actions

#550

Post by mikepurvis »

squiggleblaz wrote: post #546
mikepurvis wrote: post #389

Earlier quoted context omitted.

Strongly isolated systems like Nix and Bazel are amazing for giving no-fuss local reproducibility. Every CI "platform" is trying to seduce you into breaking things out into steps so that you can see their little visualizations of what's running in parallel or write special logic in groovy or JS to talk to an API and generate notifications or badges or whatever on the build page. All of that is cute, but it's ultimate…

Basically an online version of nix-output-monitor. Might be half an idea. But it doesn't get you 100%: you get CI, but not CD.

Delivery meaning the deployment part? I think by necessity that does differ a bit from happens locally just because suddenly there's auth, inventory, maybe a staging target, whatever.

All of that is a lot more than what a local dev would want, deploying to their own private test instance, probably with a bunch of API keys that are read-only or able to write only to other areas meant for validation.

Post reply on HN