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

31–40 of 284 posts

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

#31

Post by masklinn »

8n4vidtmkvmk wrote: post #12
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.

Not just me then? I was trying to fix a GitHub action just today but I have no clue how I'm supposed to tear it, so I just keep making tiny changes and pushing.... Not a good system but I'm still within the free tier so I'm willing to put up with it I guess.

I think it’s everyone, debugging GH actions is absolute hell, and it gets terrifying when the action interacts with the world (e.g. creating and deploying packages to a registry).

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

#32

Post by HumanOstrich »

Imustaskforhelp wrote: post #20
joshka wrote: post #13

Earlier quoted context omitted.

Guessing it's https://github.com/mateodelnorte/meta googlefu "meta github repo"

hey thanks! definitely interesting! I do wonder if this really solves the author problem because by the looks of it , you just have to run meta command and it would run over each of the sub directory. While at the same time , I think I like it because this is what I think people refer to as "modular monolith" Combining this with nats https://nats.io/ (hey if you don't want it to be over the network , you could use na…

Modular monolith refers to the architecture of your application[1]. It's a different concept from "monorepo", although they can be used together.

I'm not sure what NATS has to do with anything in this post or discussion. Also, a modular monolith is almost the antithesis of microservices.

[1]: https://www.thoughtworks.com/en-us/insights/blog/microservic...

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

#33

Post by arghwhat »

jicea wrote: post #27
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…

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…

My "favorite" is when I see people go all in, writing thousands of lines of Jenkins-flavor Groovy that parses JSON build specifications of arbitrary complexity to sort out how to build that particular project.

"But then we can reuse the same pipeline for all our projects!"

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

#34

Post by mrweasel »

jicea wrote: post #27
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…

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 you do actually solving problems. It is my opinion that a CI/CD system needs just the following features: Triggers (source code repo, http endpoints or manually triggered), secret management and shell script execution. That's it, you can build anything using that.

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

#35

Post by dijksterhuis »

Hamuko wrote: post #23
bramblerose wrote: post #2

In the end, this is the age old "I built by thing on top of a 3rd party platform, it doesn't quite match my use case (anymore) and now I'm stuck". Would GitLab have been better? Maybe. But chances are that there is another edge case that is not handled well there. You're in a PaaS world, don't expect the platform to adjust to your workflow; adjust your workflow to the platform. You could of course choose to "step dow…

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 `include` statement to pull it all together in one main pipeline file which makes dealing with massive amounts of yaml much easier.

https://docs.gitlab.com/ee/ci/yaml/includes.html

you can also use `include` to pull in a yaml config from another project to add things like SAST on the fly.

previous workplace i had like 4 CICD template repos and constructed all 30 odd actual build repos from those four templates.

used `include` to pull in some yaml template jobs, which i made run when by doing something like (it’s been a while, might get this wrong)

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


    stages:
      - build

    job_a:
      stage: build
      extends: .job_a_from_template
      variables:
        IMAGE_NAME: "myimage"
        IMAGE_REPO: "somerepo.org"
this doesn’t run anything for `job_b_from_template` … you just end up defining the things you want to run for each case, plus any variables you need to provide / override.

you can also override stuff like rules on when it should run if you want to. which is handy.

gitlab CICD can be really modular when you get into it.

if that wasn’t the case: on me.

edit: switched to some yaml instead of text which may or may not be wrong. dunno. i have yet to drink coffee.

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

#36

Post by maccard »

jicea wrote: post #27
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…

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…

To make the thing actually fast at scale, a lot of the logic ends up being specific to the provider; requiring tokens, artifacts etc that aren't available locally. You end up with something that tries to detect if you're running locally or in CI, and then you end up in exactly the same situation.

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

#37

Post by alkonaut »

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…

That’s usually very hard or impossible for many things. The AzDo yaml consists of a lot of steps that are specific to the CI environment (fetching secrets, running tests on multiple nodes, storing artifacts of various kinds).

Even if the ”meat” of the script is a single build.ps oneliner, I quickly end up with 200 line yaml scripts which have no chance of working locally.

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

#40

Post by oefrha »

masklinn wrote: post #31
8n4vidtmkvmk wrote: post #12

Earlier quoted context omitted.

Not just me then? I was trying to fix a GitHub action just today but I have no clue how I'm supposed to tear it, so I just keep making tiny changes and pushing.... Not a good system but I'm still within the free tier so I'm willing to put up with it I guess.

I think it’s everyone, debugging GH actions is absolute hell, and it gets terrifying when the action interacts with the world (e.g. creating and deploying packages to a registry).

> it gets terrifying when the action interacts with the world (e.g. creating and deploying packages to a registry).

To be fair, testing actions with side effects on the wider world is terrifying even if you’re running it locally, maybe more so because your nonstandard local environment may have surprises (e.g. an env var you set then forgot) while the remote environment mostly only has stuff you set/installed explicitly, and you can be sloppier (e.g. accidentally running ./deploy when you wanted to run ./test). That part isn’t a GH Actions problem.

Post reply on HN