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

171–180 of 284 posts

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

#171

Post by habosa »

Shameless plug but I built GitGuard (https://gitguard.dev) to solve the "Pull request and required checks" problem mentioned here (and other problems).

Basically: you set GitGuard as your required check and then write a simple GitGuard workflow like this:

    if anymatch(pull_files,"src/backend/.*") {
      assert(checkpassed("backend-tests"))
    }
Email in my bio for anyone interested.

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

#172

Post by habosa »

ripped_britches wrote: post #147

My man/woman - you gotta try buildkite. It’s a bit more extra setup since you have to interface with another company, more API keys, etc. But when you outgrow GH actions, this is the way. Have used buildkite in my last two jobs (big US tech companies) and it has been the only pleasant part of CI.

+1

I've use Jenkins, Travis, Circle, Cirrus, GitHub Actions, and Buildkite. Buildkite is leagues ahead of all of the others. It's the only enjoyable CI system I've used.

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

#173

Post by harrall »

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…

A shell script has many extremely sharp edges like dealing with stdin, stderr, stdout, subprocesses, exit codes, environmental variables, etc.

Most programmers have never written a shell script and writing CI files is already frustrating because sometimes you have to deploy, run, fix, deploy, run, fix, which means nobody is going to stop in the middle of that and try to learn shell scripting.

Instead, they copy commands from their terminal into the file and the CI runner takes care of all the rough edges.

I ALWAYS advise writing a shell script but I know it's because I actually know how to write them. But I guess that's why some people are paid more big bux.

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

#174

Post by jamesfinlayson »

ukoki wrote: post #76
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…

> My policy is to never let pipeline DSLs contain any actual logic outside orchestration for the task, I call this “isomorphic CI” — ie: as long as you set the correct env vars, it should run identically on GitHub actions, Jenkins, your local machine, a VM etc

Yep. I remember at a previous company multiple teams had manually created steps in TeamCity (and it wasn't even being backed up in .xml files).

I just did my own thing and wrapped everything deploy.sh and test.sh and when the shift to another system came... well it was still kind of annoying, but at least I wasn't recreating the whole thing.

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

#175

Post by ecosystem »

hinkley wrote: post #109

Re: monorepo > In GitHub you can specify a "required check", the name of the step in your pipeline that always has to be green before a pull request is merged. As an example, I can say that web-app1 - Unit tests are required to pass. The problem is that this step will only run when I change something in the web-app1 folder. So if my pull request only made changes in api1 I will never be able to merge my pull request!…

This comment is way too far down the page.

If the unit tests are slow enough to want to skip them, they likely are not unit tests but some kind of service-level tests or tests that are hitting external APIs or some other source of a bad smell. If the slow thing is the build, then cache the artifact keyed off the directory contents so the step is fast if code is unchanged. If the unit tests only run for a package when the code changes, there is a lack of e2e/integration testing. So, what is OP's testing strategy? Caching? It seems like following good testing practices would make this problem disappear.

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

#176

Post by 8n4vidtmkvmk »

arccy wrote: post #73
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.

git commit --allow-empty -m "bump ci" unless your pipeline does magic with trying to detect changed files

I use Mercurial + hg-git like a weirdo. Not sure if Mercurial supports empty commits, I don't think it does.

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

#177

Post by eru »

0xbadcafebee wrote: post #152
hardwaresofton wrote: post #136

Earlier quoted context omitted.

Hey if you’ve never heard of it consider using just[0], it’s a better makefile and supports shell scripting explicitly (so at least equivalent in power, though so is Make) [0]: https://github.com/casey/just

Thank you, I have seen it, but I prefer Make.

I bet all your targets are .PHONY?

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

#178

Post by eru »

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…

> [...] instead of writing a Frankenstein of YAML and shell commands.

The 'Frankenstein' approach isn't what makes it necessarily worse. Eg Makefiles work like that, too, and while I have my reservations about Make, it's not really because they embed shell scripts.

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

#179

Post by eru »

mongol wrote: post #113
datavirtue wrote: post #100

Earlier quoted context omitted.

I just joined as the enterprise architect for company that has never had one. There is an existing devops team that is making everyone pull their hair out and I haven't had a single spare minute to dig in on their mess but this sounds early familiar.

Is this really the job of an enterprise architect? To dig into the details of a devops team's mess?

The job of senior people should mostly be to make sure the organisation runs smoothly.

If no one else is doing anything about the mess, then it falls to the senior person to sort it out.

As a rule of thumb:

- Ideally your people do the Right Thing by themselves by the magic of 'leadership'. - Second best: you chase the people to do the Right Thing. - Third: you as the senior person do the Right Thing. - Least ideal: no one fixes the mess nor implements the proper way.

I guess some people can achieve the ideal outcome with pure charisma (or fear?) alone, but I find that occasionally getting your hands dirty (option 3) helps earn the respect to make the 'leadership' work. It can also help ground you in the reality of the day to day work.

However, you are right that a senior person shouldn't get bogged down with such work. You need to cut your losses at some point.

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

#180

Post by eru »

harrall wrote: post #173
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…

A shell script has many extremely sharp edges like dealing with stdin, stderr, stdout, subprocesses, exit codes, environmental variables, etc. Most programmers have never written a shell script and writing CI files is already frustrating because sometimes you have to deploy, run, fix, deploy, run, fix, which means nobody is going to stop in the middle of that and try to learn shell scripting. Instead, they copy comma…

GitHub's CI yaml also accepts eg Python. (Or anything else, actually.)

That's generally a bit less convenient, ie it takes a few more lines, but it has significantly fewer sharp edges than your typical shell script. And more people have written Python scripts, I guess?

Post reply on HN