141–150 of 267 posts
Earlier quoted context omitted.
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.
It is concerning that GitHub hosts the majority of open-source software, while actively locking its users into a platform that is based on closed source for eerything except Git itself. This issue with Actions shows how maintaining proprietary software inevitably ends up rather low on the priority list. Adding new features is much more marketable, just like for any other software product. Enshittification ensues. For…
However, as noted in the article, Forgejo's implementation currently has all the same "package manager" problems.
To get something of a lockfile you can use the hash of the version you want to pin your dependencies: > actions/checkout@f43a0e5ff2bd294095638e18286ca9a3d1956744
It is concerning that GitHub hosts the majority of open-source software, while actively locking its users into a platform that is based on closed source for eerything except Git itself. This issue with Actions shows how maintaining proprietary software inevitably ends up rather low on the priority list. Adding new features is much more marketable, just like for any other software product. Enshittification ensues. For…
On the plus side, Forgejo Action's implementation is still actively improving, where it seems that for GitHub if it's not AI, it's not being touched. However, as noted in the article, Forgejo's implementation currently has all the same "package manager" problems.
Earlier quoted context omitted.
You might want (or _need_) to sign your binary, for example. Or you might want to trigger a deployment. Github actually is doing something right here. You can set it up as a trusted identity provider in AWS, and then use Github to assume a role in your AWS account. And from there, you can get access to credentials stored in Secret Manager or SSM.
Yes, their oidc setup was probably their last good feature back when they were actually delivering features back in 2020ish. Everyone else copied it within a few months though.
I've not understood the propensity for using yaml for CI pipelines and workflows in general. A decent programming language would be a big improvement. Why not just build the workflows themselves as docker images? I guess running other docker images in the workflow would then become a problem.
Because it's clear to write and read. You don't want your CI/CD logic to end up being spaghetti because a super ninja engineer decided they can do crazy stuff just because they can. Same reason why it's a bad idea to create your infrastructure directly in a programming language (unless creating infrastructure is a core part of your software).
> Why not just build the workflows themselves as docker images? I guess running other docker images in the workflow would then become a problem.
That's how Drone CI handled it. GitLab kind of does the same, where you always start as a docker image, and thus if you have a custom one with an entrypoint, it does whatever you need it to.
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, alth…
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.
When you have a multi-platform image the actual per-platforms are usually not tagged. No point.
But that doesn't mean that they are untagged.
So on GitHub Actions when you upload a multi-platform image the per-platform show up in the untagged list. And you can delete them, breaking the multi-platform image, as now it points to blobs that don't exist anymore.
Earlier quoted context omitted.
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?
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 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.
The main problem, which this article touches, is that GHA adds a whole new dimension of dependency treadmill. You now have a new set of upstreams that you have to keep up to date along with your actual deployment upstreams.