GitHub Actions has a package manager, and it might be the worst
nesbitt.io442 points by robin_reala 6 days ago
442 points by robin_reala 6 days ago
While I hate defending GHA, the docs do include this:
- Using the commit SHA of a released action version is the safest for stability and security.
- If the action publishes major version tags, you should expect to receive critical fixes and security patches while still retaining compatibility. Note that this behavior is at the discretion of the action's author.
So you can basically implement your own lock file, although it doesn't work for transitive deps unless those are specified by SHA as well, which is out of your control. And there is an inherent trade-off in terms of having to keep abreast if critical security fixes and updating your hashes, which might count as a charitable explanation for why using hashes is less prevalent.
On the other hand, this issue has been known to GitHub since shortly after Actions’ release[0]. They added some cya verbiage to their docs, but they never followed up by making version pinning meaningful.
Sure you can implement it yourself for direct dependencies and decide to only use direct dependencies that also use commit sha pinning, but most users don’t even realize it’s a problem to begin with. The users who know often don’t bother to use shas anyway.
Or GitHub could spend a little engineer time on a feasible lock file solution.
I say this as somebody who actually likes GitHub Actions and maintains a couple of somewhat well-used actions in my free time. I use sha pinning in my composite actions and encourage users to do the same when using them, but when I look at public repos using my actions it’s probably 90% using @v1, 9% @v1.2 and 1% using commit shas.
[0] Actions was the first Microsoft-led project at GitHub — from before the acquisition was even announced. It was a sign of things to come that something as basic as this was either not understood or swept under the rug to hit a deadline.
> it doesn't work for transitive deps unless those are specified by SHA as well, which is out of your control
So in other words the strategy in the docs doesn't actually address the issue
There's a repository setting you can enable to prevent actions from running unless they have their version pinned to a SHA digest. This setting applies transitively, so while you can't force your dependencies to use SHA pinning for their dependencies, you can block any workflow from running if it doesn't.
A lockfile would address this issue, with the added benefit that it would work
Using an SHA is an anti-pattern for me. Because by using one, you kind of modeled "I am getting this fixed/static thing"; when in reality, it is very far from that. I got bitten by it twice that I learned that you either have a lock file or you don't.
- Using the commit SHA of a released action version is the safest for stability and security.
This is not true for stability in practice: the action often depends on a specific Node version (which may not be supported by the runner at some point) and/or a versioned API that becomes unsupported. I've had better luck with @main.
Depends what you mean by stability. The post is complaining about the lack of lockfiles, and the problem you describe would also be an issue with lockfiles.
The underlying problem is that you can't keep using the same version, and one way it fails ruins the workaround for a different failure.
What’s more, GitHub has basically stopped maintaining their own actions, pushing people to sketchy forks to do basic things. Their entire ecosystem is basically held up with duct tape and gets very little investment.
> Their entire ecosystem is basically held up with duct tape and gets very little investment.
That isn't gonna get better anytime soon.
"GitHub Will Prioritize Migrating to Azure Over Feature Development" [1]
[1] https://thenewstack.io/github-will-prioritize-migrating-to-a...
Hey at least we can all expect lots of extra days off because "GitHub is down" once they're done with that migration!
They had working infra and a great case for keeping fairly "close to the metal". Complicated files-heavy workload that needs tons of clever caching to perform well, lots of writes, lots of non-HTTP TCP traffic.
Retrofitting that into "cloud" bullshit is such a bad idea.
meh, I dunno.
Using bare-metal requires competent Unix admins, and Actions team is full of javascript clowns (see: decision to use dashes in environment variable; lack of any sort of shell quoting support in templates; keeping logs next to binaries in self-hosted runners). Perhaps they would be better off using infra someone else maintains.
> requires competent Unix admins
> Perhaps they would be better off using infra someone else maintains.
> Using bare-metal requires competent Unix admins
So does running VMs in a cloud provider.
Except now we call them "DevOps" or "SRE" and pay them 1.5-2x.
(as a former SRE myself, I'm not complaining).
They barely maintain Azure pipeline tasks / actions as well.
We had a critical outage because they deprecated Windows 2019 agents a month earlier than scheduled. MS support had the gall to both blame us for not migrating sooner, and refuse to escalate for 36 hours!
What? No they didn't. They extended the deprecation timeline for Windows 2019 agents from the original EOL date of 30 June 2025 to 31 December 2025; with a well-published brownout period from 2 December to 9 December in addition to the original brownout period from 3 June to 24 June.
The initial banners and warning emails about it went out well ahead of the original EOL timeline; and again as the extended EOL drew close.
If you were caught off guard by the brownout period, it's your devops team that's to blame, not Microsoft; and Microsoft was absolutely right to blame you for not migrating sooner. They gave you an extra 6 months to do it because you should have had all this done back in the first half of the year.
(If you want to blame Microsoft for anything here, blame them for not having a comprehensive tool to identify all your windows-2019 pipelines and instead just relying on "just go look at the latest pipeline runs page and hope everything's run recently enough to be on that".)
An interesting things is that GitHub is an expensive service and my guess would be that MS makes good money on it. Our small company paid about 200+ USD monthly for GitHub, much larger cumulative cost than Windows licenses. My believe was that Windows is getting worse, because it is considered legacy business by MS in favor of new offerings such as GitHub subscriptions.
Very many more people use Windows to GitHub.
GitHub also runs a free tier with significant usage.
There are ~1.4b paid instances of Windows 10/11 desktop; and ~150m Monthly active accounts on GitHub, of which only a fraction are paid users.
Windows is generating something in the region of $30b/yr for MS, and GitHub is around $2b/yr.
MS have called out that Copilot is responsible for 40% of revenue growth in GitHub.
Windows isn't what developers buy, but it is what end users buy. There are a lot more end users than developers. Developers are also famously stingy. However, in both products the margin is in the new tech.
github value maybe as not apparent as other product
but github is pair well with MS other core product like Azure and VS/VSC department
MS has a good chance to have vertical integration on how software get written from scratch to production, if they can somehow bundle everything to all in one membership like Google one subs, I think they have a good chance
I was surprised to learn that Depot runners, which are much faster, are also much cheaper. Would highly recommend them for anyone trapped on GitHub.
Blacksmith.sh has been great for us. Massively sped up tests and a huge improvement for Docker builds over both Actions and Google Cloud Build.
Only downside is they never got back to us about their startup discount.
hey there! blacksmith solutions engineer here :) love to hear we've helped speed up your tests and docker builds!!
could you shoot me your GH org so I can apply your startup discount? feel free to reach out to support@blacksmith.sh and I'll get back to you asap. thanks for using blacksmith!
Yeah, but I have to set that up.
GitHub actions more or less just work for what most people need. If you have a complex setup, use a real CI/CD system.
I haven’t use depot but I’m pretty sure the setup is literally just switching out the runs-on value in your workflows
Such as?
Jenkins is open source and very well documented.
GitHub Actions are really for just short scripts. Don't take your Miata off road.
LOL, I worked on the Jenkins project paid for three years. Even they use actions to build Jenkins.
https://github.com/jenkinsci/jenkins/tree/master/.github/wor...
Jenkins! For the love of god don’t listen to this.
Always open to learning, what's wrong with Jenkins?
It's a bit bloated, but it's free and works.
Fragile against upgrades, tons of unmaintained plugins, admin panel UX is a mess where you struggle to find the stuff your are looking for, half backed transition to nicer UI (Blue Ocean) that has been ongoing for years, too many ways to setup jobs and integrates with repos, poor resource management (disk space, CPU, RAM), sketchy security patterns inadvertently encouraged.
This stuff is a nightmare to manage, and with large code bases/products, you need a dedicated "devops" just to babysit the thing and avoid it becoming a liability for your devs.
I'm actually looking forward our migration to GHEC from on-prem just because Github Actions, as shitty as they are, are far less of an headache than Jenkins.
Why is gha just for short scripts, out of interest?
It's just short on features.
I get the vibe it was never intended to seriously compete with real CI/CD systems.
But then people started using it as such, thus this thread is full of complaints.
Thank you for the kind shout out! Always happy to see comments like this. If anyone is looking for a better GitHub or GitHub Actions experience, feel free to reach out anytime.
What are Depot runners?
Founder of Depot here. We provide faster and more reliable GitHub Actions runners (as well as other build performance services) at half the cost of GitHub [0]
Is there a write up on the security of actions or equivalent that explains how they are secure both with direct and transitive dependencies? If this applies to Depot.
Ah got it, thanks. I thought there was another kind of GitHub runner (like their "large" runners) that I hadn't heard of.
The legacy business usually explains why there are no new features, only minor maintenance, it doesn't explain why there is a lot of investment into work that makes it worse
It's not really that expensive. GitHub Enterprise is like $21/month/user while GitLab Ultimate was $100/month/user the last time GitLab published prices. These days GitLab Ultimate is "contact us for pricing" while the cheaper GitLab Premium is $29/month/user.
I guess Bitbucket is cheaper but you'll lose the savings in your employees bitching about Bitbucket to each other on Slack.
When’s the last time you looked at or used Bitbucket?
Like a week ago? We’re currently migrating away from it as everyone hated it.
Do we work in the same company? That said, I really don't understand why everyone hates on Bitbucket. I really thought it was _fine_ from a user perspective. Now we're on GHE and I find it a sidegrade at best.
Now for the people who were operating Bitbucket, I'm sure it's a relief.
As a user, I found Bitbucket to be a lot harder when it comes to searching and browsing code. The Markdown formatting is also more limited for documentation and the lack of Mermaid support in Markdown documents was shocking to see considering how both of the primary competitors (GitHub and GitLab) have implemented it.
> My believe was that Windows is getting worse, because it is considered legacy business by MS in favor of new offerings such as GitHub subscriptions.
What if GH actions is considered legacy business in favour of LLMs?
I wouldn't be surprised if there isn't some plan to make all of GitHub's backend "legacy"
and switch everyone to the dumpster fire that is Azure DevOps
and if you thought GitHub Actions was bad...
When Microsoft bought GitHub they cancelled GitHubs own early CI effort and rebranded the existing Azure DevOps as GitHub Actions.
The GitHub Actions runner source code is all dotnet. GitHub was a Ruby shop.
I believe the original GitHub Actions was in Go - it used HCL which was at that point only really implemented in Go. Quite the move backwards to switch to YAML.
IIRC Azure DevOps was the “dead one”, all new development only takes place on GitHub.
From my perspective, Azure Pipelines is largely the same as GitHub Actions. I abhor this concept of having abstract and opaque “tasks”.
There's direct evidence that GitHub Actions was the rewrite of Azure Pipelines that was originally planned to finish 5 years ago and got "stuck" (because all their resources moved to GitHub). For a while you could find 2020 roadmap repositories (on GitHub) for AzDO talking up a Pipelines rewrite bringing a lot more features (including better Docker alignment versus Pipelines' much more complex "runner skills") that instead showed up in the first version of GitHub Actions.
Microsoft claims Azure DevOps still has a roadmap, but it's hard to imagine that the real roadmap isn't simply "Wait for more VPs in North Carolina to retire before finally killing the brand".
> I wouldn't be surprised if there isn't some plan to make all of GitHub's backend "legacy"
> and switch everyone to the dumpster fire that is Azure DevOps
The other way around. Azure DevOps is 1/2 a backend for Github these days. Github re-uses a lot of Azure Devops' infrastructure.
github doesn't pay microsoft for the azure runners. that's why they came up with actions at all. microsoft gets streetcreds for stable runners, github could replace travis and appveyor.
The quality of setup-* actions has definitely gone down and there are a lot of strange decisions being made. I assume the original authors of these actions have long left the company.
This is the first time I've heard of this, do you happen to have an example?
https://github.com/search?q=org%3Aactions+%22we+are+allocati...
i.e. from https://github.com/actions/cache/?tab=readme-ov-file#note
Thank you for your interest in this GitHub repo, however, right now we are not taking contributions.
We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time. The GitHub public roadmap is the best place to follow along for any updates on features we’re working on and what stage they’re in.That's insane, so they are basically dropping support on a core feature of GH Actions?
What they are really saying is they don't want third party contributions. They don't have anyone triaging Issues or PRs so don't send them.
They will occasionally make changes if it aligns with a new product effort driven from within the org.
Saying they're dropping support is a stretch esp as very few people actually pay for their Support package anyway..... (Yes they do offer it as a paid option to Enterprise customers)
This is on the checkout action too, by the way. You know, the very first thing people put in their CI pipeline.
Wow, Microsoft just can't stop taking a dump on their users
they probably have a half-assed plan to push some sort of checkout action copilot button instead of dependable scripts/actions.
https://githubnext.com/projects/agentic-workflows/
> Instead of writing bespoke scripts that operate over GitHub using the GitHub API, you describe the desired behavior in plain language. This is converted into an executable GitHub Actions workflow that runs on GitHub using an agentic "engine" such as Claude Code or Open AI Codex. It's a GitHub Action, but the "source code" is natural language in a markdown file.
This seems like a real headache to me. I understand the value proposition of LLMs in the development cycle, but CI/CD is probably the last place where I want any degree of nondeterminism.
This looks like backwards. I would understand using a LLM to generate a GitHub Actions YAML, but always running your action from a Markdown file seems extremely wasteful in terms of resources.
Edit: ok, looking at example it makes more sense. The idea is to run specific actions that are probably not well automated, like generating and keeping documentation up-to-date. I hope people don't use it to automate things like CI runs though.
Because they know most abusive business relationship partners don't leave (see also Oracle). No matter how many bruises, CIO's are not going to get fired for buying Big Blue or whoever is the current abusive standard.
The funny thing about the last one is that those actions ultimately boil down to invoking their CLI tool (which is pre-installed on the runners) with "gh release create ...", so you can just do that yourself and ignore the third-party actions and the issues that come with them. Invoking an action isn't really any easier than invoking the CLI tool.
Yeah, what really needs to happen with that repo is to put that in the README to use the gh CLI instead of pointing to the third-party action with questionable security policies. If they were accepting PRs for that repo, it would be an easy PR to make.
That issue with their own small private forks has actually raised its head while testing out the AI slop generator thing it has, making anything it produces for you not self hoatable unless you rewrite a lot of basic functions. Sweet irony.
Which is strange because they have infinite Microsoft money and can print more if they get it into enterprises.
(we run a private gitlab instance and a merge request can spawn hundreds of jobs, that's a lot of potential Gitlab credits)
With AI you won't need CI anymore, it's all going straight to prod anyway /s
Actions is one thing, but after all these years where the new finegrained access tokens aren't still supported across all the product endpoints (and the wack granularity) is more telling about their lack of investment in maintenance.
I never used any actions and never understood why would I need to. I just wrote bash script to build my project and that's about it. This modern tendency to add dependencies for trivial things baffles me. You don't need "action" to do `git clone`.
bash scripts are as inscrutable as any GHA.
They are perfectly supportable and auditable as you're writing them yourself. It's just ordinary shell commands, there's nothing inscrutable about it.
Everyone is free to use alternative CI/CD workflow pipelines. These are often better than Github Actions.
These include
- Gitlab
Open source:
- https://concourse-ci.org/ (discussed in the context of Radicle here https://news.ycombinator.com/item?id=44658820 )
- Jenkins
-etc.
Anyone can complain as much as they want, but unless they put the money where their mouth is, it's just noise from lazy people.
I’d appreciate not being called lazy for mentioning a lack of investment on Microsoft’s side to secure their paid and fairly lucrative service that they bought a popular code hosting platform to integrate with.
Can someone explain what this somewhat recent phenomenon is where people feel the need to defend the worlds biggest billion dollar businesses, that are also often subsidized by tax payer money in weird ways?
How did we go in 20 years from holding these companies to account when they'd misbehave to acting as if they are poor damsels in distress whenever someone points out a flaw?
> How did we go in 20 years from holding these companies to account when they'd misbehave to acting as if they are poor damsels in distress whenever someone points out a flaw?
Honestly I think the problem is more a rosy view of the past versus any actual change in behavior. There have always been defenders of such companies.
> How did we go in 20 years from holding these companies to account when they'd misbehave to acting as if they are poor damsels in distress whenever someone points out a flaw?
They hired a ton of people on very very good salaries
I think big tech being so big now that these "issue" is too small for their priority is saying something
You better thank god for MS for being lazy and incompetent, the last thing we want for big tech is being innovative and have a stronger monopoly
The original comment said to stop giving money to these companies if they are not giving you a satisfactory service.
The opposite, to be lazy and to continue giving them money whilst being unhappy with what you get in return, would actually be more like defending the companies.
The original comment actually criticized Microsoft for a lack of investment to secure their paid and fairly lucrative service that they bought a popular code hosting platform to integrate with.
The opposite we see here: to not criticize them; to blame Microsoft's failure on the critics; and even to discourage any such criticism, are actually more like defending large companies.
It is a lucrative service just because people are lazy and keep buying from Microsoft. Otherwise, they would migrate to better alternatives.
This especially includes governments and other institutional buyers.
I won't "defend" Microsoft in this case, but I am always annoyed by phrases like "world's biggest billion-dollar businesses... bablah".
Their size or past misbehaviors shouldn't be relevant to this discussion. Bringing those up feels a bit like an ad hominem. Whether criticism is valid should depend entirely on how GitHub Actions actually works and how it compares to similar services.
Ad hominem applies to people. Corporations aren’t people, and ICs aren’t corporations.
> Their size or past misbehaviors shouldn't be relevant to this discussion.
If the past misbehaviours are exactly the same shape, there's not all that much point re-hashing the same discussion with the nouns renamed.
Microsoft's past behavior _may_ explain *why* there is a lack of investment in Github Actions; so yes, TheFeelz are relevant.
Then I agree with this. But still feel their size is irrelevant.
Their size is relevant in so far as it allows them to make really any investment they want to in GHA without it causing a cash flow problem.
There is a massive problem in open source where some people equate pointing out a problem with being too lazy to solve it — when in reality this just stifles the conversation. Especially when a prerequisite to any group project accomplishing anything is to first discuss the problem to be solved.
No that's actually a completely different issue. You're talking about volunteers working on side projects that are sometimes foundational to the way the internet works and then people feel entitled to tell them what to do without contributing.
Here we are talking about one of the worlds most valuable companies that gets all sorts of perks, benefits and preferential treatment from various entities and governments on the globe and somehow we have to be grateful when they deliver garbage while milking the business they bought.
No, that's actually the same issue. "Entitled to tell them what to do without contributing" is not a problem. Let them tell whoever what to do, the response is always the same: "patches welcome," or if that isn't even true (which it doesn't have to be), "feel free to fork."
OTOH if you didn't pay for support you shouldn't expect support. 'patches welcome' is a very valid response.
Is not the whole FOSS movement about receiving something you did not pay for? Going as far as to say that’s even what users deserve?
don't confuse 'receiving something you did not pay for' with 'being allowed to feel entitled to anything' is all. 'open source' is just that, nothing more. if you want a service with your source, be prepared to sponsor it.