Comment by saagarjha
8 days ago
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.
8 days ago
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.
3 replies →
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".)
Except actions/ai-task. Im sure that one will come.
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.
2 replies →
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.
11 replies →
Depot.dev is great.
1 reply →
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?
3 replies →
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?
3 replies →
> 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.
1 reply →
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”.
1 reply →
> 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
That's insane, so they are basically dropping support on a core feature of GH Actions?
8 replies →
https://github.com/orgs/actions/repositories?language=&q=&so...
https://github.com/actions/create-release
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.
1 reply →
Didn't they announce to slow down development for AI?
you just described every microsoft business model.
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
- 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?
12 replies →
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.
6 replies →
Well, actually, no, not everyone is free to use alternatives. Anyone using CI for "Trusted Publishing" of packages to PyPI or npm needs to use GitHub Actions or GitLab CI/CD. CircleCI and Travis CI are not supported. So many big open source projects for the two most popular languages in the world are now locked out of the alternatives you propose.
(I find it extremely sketchy from a competition law perspective that Microsoft, as the owner of npm, has implemented a policy banning npm publishers from publishing via competitors to GitHub Actions - a product that Microsoft also owns. But they have; that is the reality right now, whether it's legal or not.)
I was never convinced that trusted publishing solves any security problem, other than letting pypi eventually solve the problem of banning russian/iranian/whatever people just by relying on github doing it for them.
Trusted Publishing on PyPI supports Google Cloud and ActiveState as well. It’s not tied to GitHub or GitLab. To my recollection I looked at CircleCI support a while back, and ran into limitations on the claims they exposed.
(It can also be extended to arbitrary third party IdPs, although the benefit of that is dependent on usage. But if you have another CI/CD provider that you’d like to integrate into PyPI, you should definitely flag it on the issue tracker.)
> unless they put the money where their mouth is, it's just noise
I used to work for a Japanese company, and one of their core philosophies was “Don’t complain, unless you have a solution.” In my experience, this did not always have optimal outcomes: https://littlegreenviper.com/problems-and-solutions/
My favorite retort to that is, "I don't have to know how to fix it to know my arm is broken."
1 reply →
I don’t make the purchasing decision for my employer, but I certainly have to deal with their fallout, so I’ll keep complaining if that’s okay with you.
If you are not part of the solution, then you are part of the problem.
3 replies →
I've used CircleCI quite a bit in the past; it was pretty good. Feels tough for them to compete with GHA though when you're getting GHA credits for free with your code hosting.
I used Travis rather longer ago, it was not great. Circle was a massive step forward. I don't know if they have improved it since but it only felt useful for very simplistic workflows, as soon as you needed anything complex (including any software that didn't come out of the box) you were in a really awkward place.
CircleCI made great steps the last few years, f.e. to better support proper DRY working, supporting OPA policies-as-code, VSCode extensions with "dry-run" options.
For some examples of more advanced usecases take a look: https://circleci.com/blog/platform-toolkit/
Disclaimer: i work for CircleCI.
1 reply →
I had a considerably better time with CircleCI in the past than with Github Actions currently. It feels much more like a complete product rather than a tacked on mess, I hate how disproportionately we count running cost just because we have numbers for it (vs. DX and velocity which are hard to measure and impossible to predict)
I mean, they do have a free plan with 6,000 minutes
> 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.
Once I'm encharged of budge decisions of my company I'll make sure that none will go to any MS and Atlassian product. Until then I'll keep complaining.
It should be highlighted that Gitlab CI/CD (self-hostable runner and GitLab itself) is also OSS.
I'm a huge fan of: https://onedev.io/ it might not the best, but it's fast it and does it's job!
Or roll your own
I tried to use CircleCI and I gotta say, it is absolutely not better than GitHub Actions…
I have also used Travis. Ditto.
Github Actions is actually one of the better CI options out there, even if on an absolute scale it is still pretty bad.
As far as I can tell nobody has made a CI system that is actually good.
5 replies →
CircleCI is 100% trash.
Don't waste your time
It sounds like you've never worked in a large org before.
according to travis-ci, Microsoft uses that? Lol
You're falling for a marketing trick.
What that type of section usually means is "there's someone from Microsoft that signed up for our service using his work account", sometimes it means "there's some tiny team within Microsoft that uses our product", but it very rarely (if ever) means "the entire company is completely reliant on our product".
1 reply →