Live data from Hacker News

GitHub Actions is the weakest link

nesbitt.io

31–40 of 95 posts

Re: GitHub Actions is the weakest link

#31
post #14

I apologize in advance for the plug. I've spent the last 5 years warning of the importance of not leaving CI locked in a black box platform and proprietary DSL. All the while going on a quest to reinvent CI as an open, programmable platform. Honestly it's still a work-in-progress: it turns out that reinvention is hard! But, if you want a glimpse of what CI can be when you shed 30 years of legacy, consider checking ou…

A while ago I checked this out and the homepage looked like it had fallen to the 'AI hype' trend, you know like how everything was 'AI-native XYZ for Autonomous Agents' at the time. I'm not seeing that now though.

Am I thinking of someone else or did you reverse on that?

Re: GitHub Actions is the weakest link

#32
post #14

I apologize in advance for the plug. I've spent the last 5 years warning of the importance of not leaving CI locked in a black box platform and proprietary DSL. All the while going on a quest to reinvent CI as an open, programmable platform. Honestly it's still a work-in-progress: it turns out that reinvention is hard! But, if you want a glimpse of what CI can be when you shed 30 years of legacy, consider checking ou…

A while ago I checked this out and the homepage looked like it had fallen to the 'AI hype' trend, you know like how everything was 'AI-native XYZ for Autonomous Agents' at the time. I'm not seeing that now though. Am I thinking of someone else or did you reverse on that?

Yes, that was us. And yes, we reversed on that. The feedback from our community was quite clear :)

Re: GitHub Actions is the weakest link

#33
post #4

Back when GitHub Actions first came out, I used commit hashes rather than tags in all my `uses:` lines. Some of my colleagues disagreed, saying that tags were secure enough. I eventually said, "Well, for well-known actions like actions/checkout, sure; if that one gets compromised it'll be all over the news within minutes." But for all the third-party actions, I kept commit hashes. I feel rather vindicated now. There'…

There are downsides to it though. You... - lose vulnerability alerts - increase maintenance overhead - take on all that for value that will go to 0 once Immutable Releases gets widely adopted

I wrote a couple of blog posts on it, and a makeshift way of tackling that https://developerwithacat.com/blog/202604/github-actions-sup...

Re: GitHub Actions is the weakest link

#34
post #4

Back when GitHub Actions first came out, I used commit hashes rather than tags in all my `uses:` lines. Some of my colleagues disagreed, saying that tags were secure enough. I eventually said, "Well, for well-known actions like actions/checkout, sure; if that one gets compromised it'll be all over the news within minutes." But for all the third-party actions, I kept commit hashes. I feel rather vindicated now. There'…

I feel pretty happy we use Renovator (EDIT: It's Renovate) at my current workplace which by default will raise PRs to change any tags for actions with the SHA instead. Then, even when it bumps the version in future PRs, it bumps the SHA (with a comment of which tag version it represents)

If you auto merge those PRs you're back to square 1 as you're not vetting your dependency updates. And if you don't, you incur operational overhead unless you put in a fair amount of effort centralizing. Wrote a couple of posts that touched on this https://developerwithacat.com/blog/202604/github-actions-sup...

Re: GitHub Actions is the weakest link

#35
I thought GitHub was great back in the day. My account goes back to 2009. It was so much better than what came before, e.g. Sourceforge. Admittedly, the centralised nature was a problem.

I was heartbroken when Microsoft bought it. There should be a way for citizens to rebel against such things. It feels like it's been on a downward trajectory ever since.

Re: GitHub Actions is the weakest link

#36
post #14

I apologize in advance for the plug. I've spent the last 5 years warning of the importance of not leaving CI locked in a black box platform and proprietary DSL. All the while going on a quest to reinvent CI as an open, programmable platform. Honestly it's still a work-in-progress: it turns out that reinvention is hard! But, if you want a glimpse of what CI can be when you shed 30 years of legacy, consider checking ou…

Looks cool. Can it be self hosted? I.e. can I self host it next to my self hosted forgejo instance?

Yes, the Dagger engine is open source. Note that the engine on its own is not a CI replacement: it provides a runtime for your pipelines, but you still need an external system to trigger pipelines from git events. This decoupling is intentional, because CI should not be tightly coupled to git events. Sometimes you want to run a pipeline after pushing; but sometimes you need it before pushing, or even before committing. The pipeline runtime therefore should operate at a different layer than git events.

In practice this means you can combine Dagger with, say, Github Actions or another "legacy" CI platform. And use it as runner & event infrastructure for your portable Dagger pipelines.

We also offer a complete Dagger-native CI platform, which combines hosted Dagger engines, git triggers, and all the infrastructure necessary to run your CI end-to-end. That is in early access as part of Dagger Cloud, our commercial offering.

Re: GitHub Actions is the weakest link

#37
post #12
post #4

Back when GitHub Actions first came out, I used commit hashes rather than tags in all my `uses:` lines. Some of my colleagues disagreed, saying that tags were secure enough. I eventually said, "Well, for well-known actions like actions/checkout, sure; if that one gets compromised it'll be all over the news within minutes." But for all the third-party actions, I kept commit hashes. I feel rather vindicated now. There'…

GitHub Actions doesn't have a lock file, so your repo is still prone to transitive attacks if the SHA-locked actions you use also happen to use other composite actions by tags, which could be compromised in the future.

Agreed. Good news is GitHub will address that with Immutable Releases https://github.blog/news-insights/product-news/whats-coming-... You won't even need to use commit SHA as long as the maintainer follows this approach.

Re: GitHub Actions is the weakest link

#38
post #14

I apologize in advance for the plug. I've spent the last 5 years warning of the importance of not leaving CI locked in a black box platform and proprietary DSL. All the while going on a quest to reinvent CI as an open, programmable platform. Honestly it's still a work-in-progress: it turns out that reinvention is hard! But, if you want a glimpse of what CI can be when you shed 30 years of legacy, consider checking ou…

No apology necessary - I appreciate the straightforward offer of solutions to difficult problems.

Re: GitHub Actions is the weakest link

#39
post #24

Yup! Still haven't switched off of Github, but considering it at this point. If you're in my shoes, here's some tools we use that help: - https://github.com/sethvargo/ratchet for pinning external Actions/Workflows to specific commit hashes - https://www.warpbuild.com/ for much faster runners (also: runs-on/namespace/buildjet/blacksmith/depot/... take your pick) - soon moving to Buildkite for orchestration of our CI j…

Why warpbuild over the alternatives? I've seen depot before and am tempted, but open to other platforms.

Founder of WarpBuild here. We have faster compute: baremetal for amd64 workloads, AWS for arm64 etc.

We optimize for overall performance in real world jobs and have a broad selection of regions/OSes/arch available. There aren't any fixed subscription fees either.

Re: GitHub Actions is the weakest link

#40

Programming in YAML has always seemed crazy to me. Actions seem like a great place to create a simple mixed imperative/declarative scripting language (js extension or whatever) with a solid instrumented/observable/debuggable runtime and an OO API that can be run locally against mock infrastructure.

YAML isn't the problem. It's that every single action is basically curl-to-sudo-bash. Even disregarding the security implications, the ergonomics are truly horrendous. They were with Azure DevOps and they certainly are with GitHub Actions. Bad interfaces, surprising behavior, it's got it all.

CI must only consist of shell commands. No abstractions, no surprises. (Except maybe with PowerShell, where the principle of most surprise rules.)

Post reply on HN