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

251–260 of 284 posts

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

#251

Post by cnunciato »

whstl wrote: post #224
cnunciato wrote: post #149

Earlier quoted context omitted.

>Lack of local development. It's a known thing that there is no way of running GitHub Actions locally. This is one thing I really love about Buildkite[0] -- being able to run the agent locally. (Full disclosure: I also work for Buildkite.) The Buildkite agent runs as a normal process too (rather than as a Docker container), which makes the process of workflow development way simpler, IMO. I also keep a handful of age…

Are you two talking about the same thing? I believe the grandparent is talking about running it locally on development machines, often for testing purposes. Asking because Github Action also supports Self-Hosted runners [1]. [1] https://docs.github.com/en/actions/hosting-your-own-runners/...

Same thing, yeah, IIUC (i.e., running the agent/worker locally for testing). It's conceptually similar to self-hosted runners, yes, but also different in a few practical ways that may matter to you, depending on how you plan to run in production.

For one, with GitHub Actions, hosted and self-hosted runners are fundamentally different applications; hosted runners are fully configured container images, (with base OS, tools, etc., on board), whereas self-hosted runners are essentially thin, unconfigured shell scripts. This means that unless you're planning on using self-hosted runners in production (which some do of course, but most don't), it wouldn't make sense to dev/test with them locally, given how different they are. With Buildkite, there's only one "way" -- `buildkite-agent`, the single binary I linked to above.

The connection models are also different. While both GHA self-hosted runners and the Buildkite agent connect to a remote service to claim and run jobs, GHA runners must first be registered with a GitHub org or repository before you can use them, and then workflows must also be configured to use them (e.g., with `runs-on` params). With Buildkite, any `buildkite-agent` with a proper token can connect to a queue to run a job.

There are others, but hopefully that gives you an idea.

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

#252

Post by homebrewer »

nunez wrote: post #55

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.

Woodpecker supports running jobs on your own machine (and conveniently provides a command to do that for failed jobs), uses the same sane approach of passing your snippets to the shell directly (without using weird typescript wrappers), and is pluggable into all major forges, GitHub included.

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

#254

Post by ryanisnan »

mdaniel wrote: post #165
ryanisnan wrote: post #104

One really interesting omission to this post is how the architecture of GitHub actions encourages (or at the very least makes deceivingly easy) making bad security decisions. Common examples are secrets. Organization or repository secrets are very convenient, but they are also massive security holes just waiting for unsuspecting victims to fall into. Repository environments have the ability to have distinct secrets,…

> Search for and leak `AWS_ACCESS_KEY_ID` anyone? Well that's just someone being a dumbass, since AssumeRoleWithWebIdentity (and its Azure and GCP equivalent) have existed for quite a while. It works flawlessly and if someone does do something stupid like `export HURP_DURP=$AWS_ACCESS_KEY_ID; printenv` in a log, that key is only live for about 15 minutes so the attacker better hurry Further, at least in AWS and GCP (…

Great points. I totally agree, don't use hard-coded static creds, especially here. But in reality, many services and/or API keys don't support OIDC or short-lived credentials, and the design of secrets in GitHub promote using them, in my opinion.

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

#255

Post by hinkley »

maccard wrote: post #222
hinkley wrote: post #145

Earlier quoted context omitted.

10 years ago my very testing-competent coworker had us running 4200 tests in 37 seconds. In NodeJS. We should be doing as well that today without a gifted maintainer.

I've got an i9 and an NVMe drive. running npm test with 10k no-op tests takes 30 seconds, which is much quicker than I expected it to be (given how slow everything else in the node world is). Running dotnet test on the other hand with 10k empty tests took 95 seconds. Honestly, 10k no-op tests should be limited by disk IO, and in an ideal world would be 10 seconds.

> disk IO

How many tests did you put in each file?

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

#256

Post by necovek »

vvillena wrote: post #92
reactordev wrote: post #78

Earlier quoted context omitted.

This is the only DevOps way. Abstract the build into a single step.

And yet, you would be surprised at the amount of people who react like that's an ignorant statement ("not feasible in real world conditions"), an utopic goal ("too much time to implement"), an impossible feat ("automation difficults human oversight"), or, my favorite, the "this is beneath us" excuse ("see, we are special and this wouldn't work here"). Automation renders knowledge into a set of executable steps, which…

Building a Github-specific CI pipeline similarly transfer it into a set of executable steps.

The only difference is that you are now tied to a vendor for executing that logic, and the issue is really that this tooling is proprietary software (otherwise, you could just take their theoretical open source runner system and run it locally).

To me, this is mostly a question of using non-open-source development tools or not.

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

#257

Post by necovek »

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 think it's mostly obvious how you could implement CI with "local-first" programs (scripts?), but systems like Github provide value on top by making some of the artifacts or steps first-class objects.

Not sure how much of that does Github do, but it could parse test output (I know we used that feature in Gitlab back when I was using that on a project), track flaky tests for you or give you a link to code for a failing test directly.

Or it could highlight releases on their "releases" page, with release notes prominently featured.

And they allow you to group pipelines by type and kind, filter by target environment and such.

On top of that, they provide a library of re-usable workflows like AWS login, or code checkout or similar.

With all that, the equation is not as clear cut: you need to figure out how to best leverage some of those (or switch to external tools providing them), and suddenly, with time pressure, just going with the flow is a more obvious choice.

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

#258

Post by necovek »

akdev1l wrote: post #86
arccy wrote: post #70

Earlier quoted context omitted.

it can be quite hard to write proper scripts that work consistently... different shells have different behaviours, availability of local tools, paths, etc and it feels like fighting against the flow when you're trying to make it reusable across many repos

Containerize the build environment so everything is captured (dependencies, build tools, etc)

If you don't value your and your developer's time, certainly, containerize everything.

I've rarely seen a feedback loop with containers that's not longer than 10s only due to containerization itself, and that breaks the "golden" 10s rule (see https://www.nngroup.com/articles/response-times-3-important-...).

If you aim for quicker turn-around (eg. just running a single test in <1s), you'll have to either aggressively optimize containers (which is pretty non-idiomatic with Docker containers in particular), or do away with them.

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

#259

Post by dayjaby »

p1necone wrote: post #97

There's a workaround for the 'pull request and required check' issue. You create an alternative 'no op' version of each required check workflow that just does nothing and exits with code 0 with the inverse of the trigger for the "real" one. The required check configuration on github is just based off of job name, so either the trigger condition is true, and the real one has to succeed or the trigger condition is fals…

Or you can just check if the step was skipped. I don't get the point of the article.

Managing a monorepo with acyclic dependencies is super easy: dornys path filter in one job and the other jobs check

1. whether their respective or any dependency's path got changed 2. and all dependency jobs were either successful or skipped.

Done. No need to write an article.

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

#260

Post by necovek »

lmm wrote: post #168
carlmr wrote: post #90

Earlier quoted context omitted.

If you're not containerizing your CI/CD, you're really lost.

Only if your tech stack is bad (i.e. Python). My maven builds work anywhere with an even vaguely recent maven and JVM (and will fail-fast with a clear and simple error if you try to run them in something too old), no need to put an extra layer of wrapping around that.

It's trivial to control your Python stack with things like virtualenv (goes back to at least 2007) and has been for ages now (I don't really remember the time when it wasn't, and I've been using Python for 20+ years).

What in particular did you find "bad" with Python tech stack?

(I've got my gripes with Python and the tooling, but it's not this — I've got bigger gripes with containers ;-))

Post reply on HN