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

111–120 of 284 posts

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

#111

Post by thayne »

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…

The problem is that your "ci" script often needs some information from the host system, like what is the target git commit? Is this triggered by a pull request, or a push to a branch? Is it triggered by a release? And if so, what is the version of the release?

IME, much of the complexity in using Github Actions (or Gitlab CI, or Travis) is around communicating that information to scripts or build tools.

That and running different tasks in parallel, and making sure everything you want passes.

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

#112

Post by tialaramex »

posix86 wrote: post #108

One thing that sounds very nice about Github are merge queues: Once your PR is ready, rather than merging, you submit it to the merge queue, which will rebase it on the last PR also on the merge queue. It then runs the CI on each PR, and finally merges them automatically once successful. If CI fails, doesn't get merged, and the next PR skips yours on the chain. Still a lot of computation & some wait time, but you can…

That sounds roughly like what happens for Rust. I write a Rust PR, somebody reviews it, they have feedback, I modify the PR, they're happy, and it passes to bors (originally: https://github.com/graydon/bors) which then tries to see whether this can be merged with Rust and if so does so.

It is nice to know that if humans thought your change is OK, you're done. I've only committed small changes (compiler diagnostics, documentation) nothing huge, so perhaps if you really get up in it that's more work, but it was definitely a pleasant experience.

... and sure enough it turns out that work on one of the bors successors was in fact discontinued because you should just use this GitHub feature. TIL.

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

#113

Post by mongol »

datavirtue wrote: post #100
mrweasel wrote: post #34

Earlier quoted context omitted.

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 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?

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

#114

Post by junto »

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

Whilst I do detest much of Azure DevOps, one thing I do like about their pipelines is that we can securely use service connections and key vaults in Azure to secure pipeline tasks that require credentials to be managed securely.

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

#115

Post by maccard »

carlmr wrote: post #90
akdev1l wrote: post #86

Earlier quoted context omitted.

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

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

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

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

#116

Post by rustd »

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

Agreed, most of the CI tools don't help in getting feedback early to the developers. I shouldn't have to wait hours for my CI job to complete. Harness is a tool that can reduce build times by caching build artifacts, docker layers and only running a subset of tests that were impacted the by the code change.

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

#117

Post by mdaniel »

electromech wrote: post #98
kjuulh wrote: post #25

I am biased because I built the rust SDK for dagger. But I think it is a real step forward for CI. Is it perfect? Nope. But it allows fixing a lot of the shortcomings the author has. Pros: - pipeline as code, write it as golang, python, typescript or a mix of thr above. - Really fast once cached - Use your languages library for code sharing, versioning and testing - Runs everywhere local, ci etc. Easy to change from…

I'm genuinely intrigued by Dagger, but also super confused. For example, this feels like extra complexity around a simple shell command, and I'm trying to grok why the complexity is worth it: https://docs.dagger.io/quickstart/test/#inspect-the-dagger-f... I'm a fanboy of Rust, Containerization, and everything-as-code, so on paper Dagger and your Rust SDK seems like it's made for me. But when I read the examples... I…

I'm merely an outsider to Dagger, but I believe the page you linked to would give one the impression "but why golang[1] around some shell literals?!" because to grok its value one must understand that m.BuildEnv(source) https://docs.dagger.io/quickstart/env#inspect-the-dagger-fun...> is programmatically doing what https://docs.github.com/en/actions/writing-workflows/workflo... would do: define the docker image (if any), the env vars (if any), and other common step parameters

That conceptually allows one to have two different "libraries" in your CI: one in literal golang, as a function which takes in a source and sets up common step configurations, and the other as Dagger Functions via Modules (https://docs.dagger.io/features/modules> or https://docs.dagger.io/api/custom-functions#initialize-a-dag...>) which work much closer to GHA uses: blocks from a organization/repo@tag style setup with the grave difference that they can run locally or in CI, which for damn sure is not true of GHA uses: blocks

The closest analogy I have is from GitLab CI (since AFAIK GHA does not allow yaml anchors nor "logical extension"):

  .common: &common #
1: I'm aware that I am using golang multiple times in this comment, and for sure am a static typing fanboi but as the docs show they allow other languages, too

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

#118

Post by rustd »

flohofwoe wrote: post #11

IMHO the main problem with GH Actions is that the runners are so slow. Feels like running your build on a frigging C64 sometimes ;)

GH hosted runners use shared hardware so the performance is never good. There are quite a few options available. Harness CI offers hyper optimized build infrastructure, paired with software intelligence (caching, running subset of tests based on the code change) can reduce build times up-to 4X compared to GH Actions.

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

#119

Post by maccard »

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

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.

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

#120

Post by rustd »

bitliner2 wrote: post #30

Welcome to the jungle. https://medium.com/@bitliner/why-gitlab-can-be-a-pain-ae1aa6... I think it’s not only GitHub. Ideally we should handle it as any other code, that is: do tests, handle multiple environments including the local environment, lint/build time error detection etc

Agree. CI should be handled as code.
Post reply on HN