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

I'll think twice before using GitHub Actions again

ninkovic.dev

Post reply on HN
Print view View original

51–60 of 284 posts

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

#51

Post by dijksterhuis »

dijksterhuis wrote: post #35
Hamuko wrote: post #23

Earlier quoted context omitted.

Doesn't everything in GitLab go into a single pipeline? GitHub at least makes splitting massive CI/CD setups easier by allowing you to write them as separate workflows that are separate files.

> GitHub at least makes splitting massive CI/CD setups easier by allowing you to write them as separate workflows that are separate files. this makes me feel like you’re really asking “can i split up my gitlab CICD yaml file or does everything need to be in one file”. if that’s the case: yes it does eventually all end up in a single pipeline (ignoring child pipelines). but you can split everything up and then use the…

addendum you can also do something like this, which means you don’t have to redefine every job in your main ci file, just define the ones you don’t want to run

    include:
      project: 'cicd/templates'
      file: 'builds.yml'

    variables:
      IMAGE_NAME: something
      IMAGE_REPO: some.org

    job_b:
      rules:
        - when: never
where the template you import has a job_a and job_b definition. both get pulled in, but job_b gets overwritten so it never runs.

less useful when just splitting things into multiple files to make life simpler.

super useful when using the same templates across multiple independent repositories to make everything build in as close to the same way as possible.

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

#52

Post by eddd-ddde »

mrweasel wrote: post #34
jicea wrote: post #27

Earlier quoted context omitted.

I don't understand why this is not the evident approach for everyone writing GitHub Actions/GitLab CI/CD yaml etc.... I've struggled in some teams to explained why it's better to extract your command in scripts (ShellCheck on it, scripts are simple to run locally etc...) instead of writing a Frankenstein of YAML and shell commands. I hope someday to find an authoritative guidelines on writing pipeline that promote th…

In a previous job we had a team tasked with designing these "modern" CI/CD pipeline solutions, mostly meant for Kubernetes, but it was suppose to work for everything. They had such a hard on for tools that would run each step as a separate isolated task and did not want pipelines to "devolve" into shell scripts. Getting anything done in such environments are just a pain. You spend more time fighting the systems than…

I think what they really wanted was something like bazel. The only real benefit I can think right now for not "devolving" into shell scripts is distributed caching with hermetic builds. It has very real benefits but it also requires real effort to work correctly.

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

#53

Post by rickette »

Every CI system has its flaws but GitHub Actions in my opinion is pretty nice especially in terms of productivity; easy to setup, tons of prebuild actions, lots of examples, etc.

I've used Tekton, Jenkins, Travis, Hudson, StarTeam, Rational Jazz, Continuum and a host of other CI systems over the years but GitHub Actions ain't bad.

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

#54

Post by angoragoats »

Why is this team sticking multiple directories that are “independent of each other” into a single repository? This sounds like a clear case of doing version control wrong. Monorepos come with their own set of challenges, and I don’t think there are many situations where they’re actually warranted. They certainly don’t help for completely independent projects.

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

#55

Post by nunez »

Posts like this make me miss Travis. Travis CI was incredible, especially for testing CI locally. (I agree with the author that act is a well done hack. I've stopped using it because of how often I'd have something pass in act and fail in GHA.)

> GitHub doesn't care

My take: GitHub only built Actions to compete against GitLab CI, as built-in CI was taking large chunks of market share from them in the enterprise.

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

#56

Post by nunez »

arghwhat wrote: post #5

> no way of running actions locally My policy is to never let pipeline DSLs contain any actual logic outside orchestration for the task, relying solely on one-liner build or test commands. If the task is more complicated than a one-liner, make a script for it in the repo to make it a one-liner. Doesn't matter if it's GitHub Actions, Jenkins, Azure DevOps (which has super cursed yaml), etc. This in turn means that you…

While youre correct, environmental considerations are another advantage that testing locally SHOULD be able to provide (i.e. you can test your scripts or Make targets or whatever in the same runner that runs in the actual build system.)

This is not possible with GHA.

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

#57

Post by nunez »

tevon wrote: post #3

I call writing GitHub Actions "Search and Deploy", constantly pushing to a branch to get an action to run is a terrible pattern... You'd think, especially with the deep VS Code integration, they'd have at least a basic sanity-check locally, even if not running the full pipeline.

Biggest pet peeve of GHA by a country mile.

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

#58

Post by arghwhat »

nunez wrote: post #56
arghwhat wrote: post #5

> no way of running actions locally My policy is to never let pipeline DSLs contain any actual logic outside orchestration for the task, relying solely on one-liner build or test commands. If the task is more complicated than a one-liner, make a script for it in the repo to make it a one-liner. Doesn't matter if it's GitHub Actions, Jenkins, Azure DevOps (which has super cursed yaml), etc. This in turn means that you…

While youre correct, environmental considerations are another advantage that testing locally SHOULD be able to provide (i.e. you can test your scripts or Make targets or whatever in the same runner that runs in the actual build system.) This is not possible with GHA.

Of course you can, just specify a container image of your choice and run the same container for testing locally.

However, replicating environmental details is only relevant where the details are known to matter. A lot of effort has been wasted and workflows crippled by the idea that everything must be 100% identical irrespective of actual dependencies and real effects.

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

#59

Post by danillonunes »

riperoni wrote: post #49
benrutter wrote: post #19

Oh boy, there's a special kind of hell I enter into everytime I set up new github actions. I wrote a blog post a few months ago about my pain[0] but one of the main things I've found over the years is you can massively reduce how horrible writing github actions is by avoiding prebuilt actions, and just using it as a handy shell runner. If you write behaviour in python/ruby/bash/hell-rust-if-you-really-want and leave…

At this point, just pause with Github Actions and compare it to how GiLab handles CI. Much more intuitive, taking shell scripts and other script commands natively and not devolving into a mess of obfuscated typescript wrapped actions that need a shit ton of dependencies.

But you can do the same with GitHub, right? Although most docs and articles focus on 3rd party actions, nothing stops you to just run everything in your own shell script.

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

#60

Post by xinayder »

I tried to use GitHub Actions on Forgejo and... It's so much worse than using an actual CI pipeline.

With Woodpecker/Jenkins you know exactly what your pipeline is doing. With GitHub actions, not even the developers of the actions themselves know what the runner does.

Post reply on HN