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

221–230 of 284 posts

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

#221

Post by maccard »

eru wrote: post #182
maccard wrote: post #115

Earlier quoted context omitted.

How do I containerize building desktop apps for windows with MSVC?

Wine? Less snarky: https://learn.microsoft.com/en-us/virtualization/windowscont... seems to be a thing? And in any case, you can use VMs instead of containers.

You know, I'd love to run MSVC in Wine on a ubuntu container. I bet it would be quicker.

I've had the unfortunate pleasure of working with Windows Containers in the past. They are Containers in the sense that you can write a dockerfile for them, and they're somewhat isolated, but they're no better than a VM in my experience.

> And in any case, you can use VMs instead of containers.

They're not the same thing. If that's the case running linux AMI's on EC2 should be the same as containers.

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

#222

Post by maccard »

hinkley wrote: post #145
maccard wrote: post #119

Earlier quoted context omitted.

I agree hardware should be that quick, but CI and cloud hardware is woefully underpowered unless you actively seek it out. I’ve also never seen a test framework spew out even close to that in practice. I’m not even sure most frameworks would do that with noop tests, which is sad.

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.

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

#223

Post by maccard »

Lutger wrote: post #216
maccard wrote: post #36

Earlier quoted context omitted.

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.

You are right, and this is where a little bit of engineering comes in. Push as much of the logic to scripts (either shell or python or whatever) that you can run locally. Perhaps in docker, whatever. All the token, variables, artifacts etc should act as inputs or parameters to your scripts. You have several mechanisms at your disposal, command line arguments, environment variables, config files, etc. Those are all we…

> The trick is to NOT have your script depend on the specifics of the environment, but reverse the dependency. So replace all `If CI then Run X else if Local Run Y` with the ability to configure the script to run X or Y, then let the CI configure X and local configure Y. For example.

> I'm not saying it is always easy and obvious. For bigger builds, you often really want caching and have shitloads of secrets and configurations going on.

Here's the thing. When you don't want secrets, or caching, or messaging, or conditional deploys, none of this matters. Your build can be make/mvn/go/cargo and it just works, and is easy. It only gets messy when you want to do "detect changes since last run and run tests on those components", or "don't build the moon and the stars, pull that dependency in CI, as local users have it built already and it won't change." And the way to handle those situations involves running different targets/scripts/whatever and not what is actually in your CI environment.

I've lost count of how many deploys have been marked as failed in my career because the shell script for posting updates to slack has an error, and that's not used in the local runs of CI.

What you _actually_ need is a staging branch of your CI and a dry-run flag on all of your state modifying commands. Then, none of this matters.

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

#224

Post by whstl »

cnunciato wrote: post #149
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…

>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/...

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

#225

Post by jcarrano »

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…

100% agree and that has been my experience too. It also makes testing the logic locally much easier, just run the script in the appropriate container.

The pipeline DSLs, because they are not full programming languages have to include lots of specific features and options and if you want something slightly outside of what they are designed for, you are out of luck. In a way it feels like how graphics were in the age of fixed-pipeline, when there had to be a complex API to cover all use cases yet it was not flexible enough.

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

#226

Post by jcarrano »

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

That is true for most cases, which nowadays is web and backend software. As you get into embedded or anything involving hardware things get slower and you need to optimize.

For example, tests involving read hardware can only run at 1x speed, so you will want to avoid running those if you can. If you are building a custom compiler toolchain, that is slow and you will want to skip it if the changes cannot possibly affect the toolchain.

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

#227

Post by jcarrano »

The general philosophy of these CI systems is flawed. Instead of CI running your code, your code should run the CI. In other words, the CI should present an API such that one can have arbitrary code which informs the system of what is going on. E.g. "I'm starting jobs A,B,C", "Job A done successfully", "This file is an artifact for job B".

Information should only from from the user scripts to the CI, and communication should be done by creating files in a specific format and location. This way the system can run and produce the same results anywhere provided it has the right environment/container.

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

#228

Post by joshstrange »

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

I never knew how easy it was to setup role assuming for AWS/GHA. It’s much easier than managing the access/secret.

I wrote a little about it in this blog post: https://joshstrange.com/2024/04/26/nightly-postgres-backups-...

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

#230

Post by akdev1l »

maccard wrote: post #221
eru wrote: post #182

Earlier quoted context omitted.

Wine? Less snarky: https://learn.microsoft.com/en-us/virtualization/windowscont... seems to be a thing? And in any case, you can use VMs instead of containers.

You know, I'd love to run MSVC in Wine on a ubuntu container. I bet it would be quicker. I've had the unfortunate pleasure of working with Windows Containers in the past. They are Containers in the sense that you can write a dockerfile for them, and they're somewhat isolated, but they're no better than a VM in my experience. > And in any case, you can use VMs instead of containers. They're not the same thing. If that…

It’s the same thing for the purposes of capturing the build environment.

It doesn’t really matter if you have to spin up a Linux instances and then run your build environment as a container there vs spinning up a windows VM.

Post reply on HN