10 ms·
GitHub Actions has a package manager, and it might be the worst
- throwawaypath 11mo agoLooks like removing the "meritocracy" doormat, hiring Coraline Ada Ehmke, and changing "master" to "main" paid off in spades!
- saagarjha 11mo agoWhat’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.
- bilekas 11mo agoThat 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.
- Cthulhu_ 11mo agoWhich 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)
- mhitza 11mo agoWith 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.
- crote 11mo agoThis is the first time I've heard of this, do you happen to have an example?
- anentropic 11mo agohttps://github.com/orgs/actions/repositories?language=&q=&sort=&type=archived https://github.com/orgs/actions/repositories?language=&q=&so... https://github.com/actions/create-release https://github.com/actions/create-release
- ptx 11mo agoThe 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.
- WorldMaker 11mo agoYeah, 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.
- coryrc 11mo agohttps://github.com/search?q=org%3Aactions+%22we+are+allocating+resources+towards+other+areas+of+Actions+and+are+not+taking+contributions+to+this+repository+at+this+time.%22&type=code https://github.com/search?q=org%3Aactions+%22we+are+allocati... i.e. from https://github.com/actions/cache/?tab=readme-ov-file#note 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.
- mixedbit 11mo agoAn 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.
- samhh 11mo agoI was surprised to learn that Depot runners, which are much faster, are also much cheaper. Would highly recommend them for anyone trapped on GitHub.
- LilBytes 11mo agoDepot.dev is great.
- kylegalbraith 11mo agoThank you! Really appreciate the support.
- 999900000999 11mo agoYeah, 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.
- bastardoperator 11mo agoSuch as?
- 999900000999 11mo agoJenkins is open source and very well documented. GitHub Actions are really for just short scripts. Don't take your Miata off road.
- silverwind 11mo agoThe 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.
- miohtama 11mo agoEveryone is free to use alternative CI/CD workflow pipelines. These are often better than Github Actions. These include - https://circleci.com/ https://circleci.com/ - https://www.travis-ci.com/ https://www.travis-ci.com/ - Gitlab Open source: - https://concourse-ci.org/ https://concourse-ci.org/ (discussed in the context of Radicle here https://news.ycombinator.com/item?id=44658820 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.
- c0balt 11mo agoIt should be highlighted that Gitlab CI/CD (self-hostable runner and GitLab itself) is also OSS.
- ramon156 11mo agoaccording to travis-ci, Microsoft uses that? Lol
- input_sh 11mo agoYou'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".
- SkyPuncher 11mo agoYes and no. Generally logo usage requires permission. While the usage isn’t the whole company, it’s enough to justify some sort of logo usage.
- koakuma-chan 11mo agoOr roll your own
- saagarjha 11mo ago
- Bombthecat 11mo agoDidn't they announce to slow down development for AI?
- souenzzo 11mo agoyou just described every microsoft business model.
- vbezhenar 11mo agoI 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`.
- wnevets 11mo ago> 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-azure-over-feature-development/ https://thenewstack.io/github-will-prioritize-migrating-to-a...
- amarant 11mo agoHey at least we can all expect lots of extra days off because "GitHub is down" once they're done with that migration!
- phantasmish 11mo agoThey 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.
- theamk 11mo agomeh, 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.
- dijit 11mo ago> 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).
- godelski 11mo ago> requires competent Unix admins Who knows where a $3.7T company is ever going to find competent Unix admins... > Perhaps they would be better off using infra someone else maintains. They're handing it from themselves to themselves. We're talking about Microsoft, not some startup.
- dwroberts 11mo agoPleased this is being discussed somewhere as it’s something that has troubled me for a while. There are so many third party actions where the docs or example reference the master branch. A quick malicious push and they can presumably exfiltrate data from a ton of repositories (Even an explicit tag is vulnerable because it can just be moved still, but master branch feels like not even trying)
- amluto 11mo ago> The researchers identified four fundamental security properties that CI/CD systems need: admittance control, execution control, code control, and access to secrets. Why do CI/CD systems need access to secrets? I would argue need access to APIs and they need privileges to perform specific API calls. But there is absolutely nothing about calling an API that fundamentally requires that the caller know a secret. I would argue that a good CI/CD system should not support secrets as a first-class object at all. Instead steps may have privileges assigned. At most there should be an adapter, secure enclave style, that may hold a secret and give CI/CD steps the ability to do something with that secret, to be used for APIs that don’t support OIDC or some other mechanism to avoid secrets entirely.
- cyberax 11mo agoYou 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.
- DuncanCoffee 11mo agoYeah I sign my project APKs so people can install them from the action's artefact - name: Retrieve keystore for apk signing env: KEYSTORE: ${{ secrets.KEYSTORE }} run: echo "$KEYSTORE" | base64 --decode > /home/runner/work/keystore.pfk
- amluto 11mo agoExactly. This workflow step takes a rather important secret and sticks it on a VM where any insufficiently sandboxed step before or after it can exfiltrate it. GitHub should instead let you store that key as a different type of secret such that a specific workflow step can sign with it. Then a compromised runner VM could possibly sign something that shouldn’t be signed but could not exfiltrate it. Even better would be to be able to have a policy that the only thing that can be signed is something with a version that matches the immutable release that’s being built.
- cyberax 11mo agoYep. I'm switching our workflows to instead use regular utilities running inside a Docker container. This works well for _most_ things. There are some issues with doing docker-in-docker for volume mapping, but they're mostly trivial. We're using taskfiles to run tasks, so I can just rely on it for that. It also has a built-in support for nice output grouping ( https://taskfile.dev/docs/reference/schema#output https://taskfile.dev/docs/reference/schema#output ) that Github actions can parse. Pros: 1. Ability to run things in parallel. 2. Ability to run things _locally_ in a completely identical environment. 3. It's actually faster! 4. No vendor lock-in. Offramp to github runners and eventually local runners? Cons: It often takes quite a while to understand how actions work when you want to run them in your own environment. For example, how do you get credentials to access the Github Actions cache and then pass them to Docker? Most of documentation just tells: "Use this Github Action and stop worrying your pretty little head about it".
- baq 11mo agoNormally I’d say stop kicking the dead horse, but GHA deserves all the complaints it gets and then some. It’s the embodiment of everything that’s bad in ‘less is more’. My biggest concern with it is that it’s somehow the de facto industry standard. You could do so much better with relatively small investments, but MS went full IE6 with it… and now there’s a whole generation of young engineers who don’t know how short their end of the stick actually is since they never get to compare it to anything.
- zahlman 11mo agoI'm accustomed to just doing as much as possible locally. GHA doesn't even seem like a value-add over that for me.
- deleted 11mo ago[deleted]
- bjackman 11mo agoIt's funny that absolutely everything about GHA fucking sucks, and everyone agrees about this. BUT, the fact that it's free compute, and it's "right there"... means it's very very difficult to say no to! Personally I've just retired a laptop and I'm planning to turn it into a little home server. I think I'm gonna try spinning up Woodpecker on there, I'm curious to see what a CI system people don't hate is like to live with!
- kminehart 11mo agoI can already tell by their example that I don't like it. I've worked with a bunch of different container-based CI systems and I'm getting a little tired seeing the same approach by done slightly differently. steps: - name: backend image: golang commands: - go build - go test - name: frontend image: node commands: - npm install - npm run test - npm run build Yes, it's easy to read and understand and it's container based, so it's easy to extend. I could probably intuitively add on to this. I can't say the same for GitHub, so it has that going for it. But the moment things start to get a little complex then that's when the waste starts happening. Eventually you're going to want to _do_ something with the artifacts being built, right? So what does that look like? Immediately that's when problems start showing up... - You'll probably need a separate workflow that defines the same thing, but again, only this time combining them into a Docker image or a package. - I am only now realizing that woodpecker is a fork of Drone. This was a huuuge issue in Drone. We ended up using Starlark to generate our drone yaml because it lacked any kind of reusability and that was a big headche. - If I were to only change a `frontend` file or a `backend` file, then I'm probably going to end up wasting time and compute rebuilding the same artifacts over and over. - GitHub's free component honestly hurts itself here. I don't have to care about waste if it's mostly free anyways. - Running locally using the local backend... looks like a huge chore. In Drone this was basically impossible. I really wish someone would take a step back and really think about the problems being solved here and where the current tooling fails us. I don't see much effort being put into the things that really suck about github actions (at least for me): legibility, waste, and the feedback loop.
- Raed667 11mo agoTo get something of a lockfile you can use the hash of the version you want to pin your dependencies: > actions/checkout@f43a0e5ff2bd294095638e18286ca9a3d1956744
- barrkel 11mo agoTransitive dependencies?
- Kovah 11mo agoYeah, only works if all used Actions would use SHAs too, which is not the case. Positive example: https://github.com/codecov/codecov-action/blob/96b38e9e60ee60a8c3911f4612407bba2f9195fb/action.yml#L233 https://github.com/codecov/codecov-action/blob/96b38e9e60ee6... Negative example: https://github.com/armbian/build/blob/54808ecff253fb71615161e3a216ad14b420022b/action.yml#L101 https://github.com/armbian/build/blob/54808ecff253fb71615161...
- cedws 11mo agoI've also found many Actions that do other dodgy stuff, like pulling and executing unpinned scripts from external websites, or installing unpinned binaries from GitHub releases. Pinning an Action isn't enough, you have to audit it.
- cyphar 11mo agoTFA mentions this option and then goes on at some length to explain that this doesn't help for transitive dependencies, which is how these attacks usually work.
- TrianguloY 11mo agoI'm not sure I follow. If I write actions/setup-python@v1, I'm expecting the action to run with the v1 tag of that repository. If I rerun it, I expect it to run with the v1 tag of that repository...which I'm aware may not be the same if the tag was updated. If I instead use actions/setup-python@27b31702a0e7fc50959f5ad993c78deac1bdfc29 then I'm expecting the action to run with that specific commit. And if I run it again it will run with the same commit. So, whether you choose the tag or the commit depends on whether you trust the repository or not, and if you want automatic updates. The option is there...isn't it?
- barrkel 11mo agoYou specifying the top level hash doesn't do anything to pin transitive dependencies, and as the article points out, transitive dependencies - especially dependencies common to a lot of actions - would be the juciest target for a supply chain attack.
- TrianguloY 11mo agoAh, I see it now. Thanks!
- eviks 11mo ago> which I'm aware may not be the same if the tag was updated. That's the mistake that breaks the following. People don't usually expect that it's an arbitrary modifiable reference, but instead that it's the same version they've picked when they created the file (ie a tag is just a human friendly name for a commit)
- LoganDark 11mo agoI checked out the linked GitHub repo https://github.com/ecosyste-ms/package-manager-resolvers https://github.com/ecosyste-ms/package-manager-resolvers and it appears to be just a README.md that collects summaries of different package managers? How do I know these weren't just LLM-generated?
- regularfry 11mo agoYou don't, but that's the wrong question. How do you know they're accurate?
- LoganDark 11mo agoI feel it's not that controversial to treat LLM output as unreliable without proper verification. So even if the output were accurate, if it's LLM-generated without proper verification I don't trust it.
- pjc50 11mo agoThis is making me feel quietly vindicated in pushing back on migrating our Jenkins/Ansible setup to GHA simply because corporate wanted the new shiny thing. Fortunately the "this will be a lot of work, i.e. cost" argument won. Mind you, CI does always involve a surprising amount of maintenance. Update churn is real. And Macs still are very much more fiddly to treat as "cattle" machines.
- ramon156 11mo agoLol at my first job I migrated our setup from GHA to Jenkins. I think they eventually went back to GHA Current job is using blacksmith to save on costs, but the reality of it is that this caching layer only adds costs in some of our projects
- sureglymop 11mo agoCI is interesting because what really happens is you run a script on someone elses computer but with fairly weird constraints. I get it's use, especially in large companies and I also get the culture leading up to it being widely used but I can't help but chuckle a bit about the problems we cause for ourselves in this industry.
- bloppe 11mo agoWhile 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.
- bramblerose 11mo ago- 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.
- bloppe 11mo agoDepends 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.
- Dylan16807 11mo agoThe underlying problem is that you can't keep using the same version, and one way it fails ruins the workaround for a different failure.
- amake 11mo ago> 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
- bluenose69 11mo agoI agree 100% with what I think is the key phrase, viz. "the results can change without any modification to your code". I maintain an R package that is quite stable and is widely used. But every month or so, the GHA on one of the R testing machines will report an error. The messages being quite opaque, I typically spend a half hour trying to see if my code is doing something wrong. And then I simply make a calendar item to recheck it each day for a while. Sure enough, the problems always go away after a few days. This might be specific to R, though.
- worldsayshi 11mo agoI'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.
- trueno 11mo agoit's wild I can wiz through a ton of code for hours on end but seeing a yaml file for something like a CI pipeline actually makes my brain eject i dunno why. my brain has some sort of proverbial capacity limit with how many different configuration-file looking things I can tolerate in a day, and the prospect of becoming intimately familiar with what is effectively an auto integration presented to me as some sort of config makes me completely unjustifiably butthurt for no reason. have i not suffered enough needless and often times limiting abstractions already
- sofixa 11mo ago> 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. 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.
- weakfish 11mo agoIME on a Pulumi for IaC team, writing infra in a real language (TypeScript) is MILES better than- you can do conditions, have typed outputs, etc and not have it be a bastardized imperative YAML mess. YAML is fine for data, but inevitably stuff like workflows end up tacking on imperative features to a declarative language.
- tom1337 11mo agoWe are currently using GitHub Actions for all our CI tasks and I hate it. Yes, the marketplace is nice and there are a lot of utility actions which make life easier, but they all come with the issues the post highlights. Additionally, testing Actions locally is a nightmare. I know that act exists but for us it wasn't working most of the time. Also the whole environment management is kinda odd to me and the fact, that when using an environment (which then allows to access secrets set in that environment) it always creates a new deployment is just annoying [1] I guess the best solution is to just write custom scripts in whatever language one prefers and just call those from the CI runner. Probably missing out on some fancy user interfaces but at least we'd no longer be completely locked into GHA... [1] https://github.com/orgs/community/discussions/36919 https://github.com/orgs/community/discussions/36919
- ignoramous 11mo ago> Some teams vendor actions into their own repos. zizmor is excellent at scanning workflows and finding security issues. But these are workarounds for a system that lacks the basics. Harsh given GitHub makes it very easy to setup attestations for Artifact (like build & sbom) provenances. That said, Zizmor (static analyser for GitHub Actions) with Step Security's Harden Runner (a runtime analyser) [0] pair nicely, even if the latter is a bit of an involved setup. [0] https://github.com/step-security/harden-runner https://github.com/step-security/harden-runner > The fix is a lockfile. Hopefully, SLSA drafts in Hermetic build process as a requirement: https://slsa.dev/spec/v1.2/future-directions https://slsa.dev/spec/v1.2/future-directions
- woodruffw 11mo agoI’d say that GitHub has done an admirable job making attestations more accessible, but that “easy” is still a stretch of a characterization: it’s still not the default, and the error/configuration states are somewhat opaque (e.g. around OIDC permissions, unprivileged triggers, what constitutes a signing identity in a reusable workflow context, etc.). Some of these are latent complexities that GitHub can’t be blamed for, but some are certainly made worse by architectural decisions in GitHub Actions.
- pshirshov 11mo agoRun Nix atop of Actions, minimize the amount of actions you depend on. That works. As a bonus, you now can run your flows locally too. I have a little launcher for that which helps: https://github.com/7mind/mudyla https://github.com/7mind/mudyla
- _cenw 11mo agoSee also this excellent video essay by fasterthanlime: GitHub Actions Feels Bad[1]. I'm pretty sure it contains the exact line of it being "deeply confused about being a package manager". [1]: https://www.youtube.com/watch?v=9qljpi5jiMQ https://www.youtube.com/watch?v=9qljpi5jiMQ
- IshKebab 11mo ago> The core problem is the lack of a lockfile. Every other package manager figured this out decades ago Well... not Pip!
- thangngoc89 11mo agoI would recommend you to try uv for this.
- notatallshaw 11mo agoWe're getting there https://pip.pypa.io/en/stable/cli/pip_lock/ https://pip.pypa.io/en/stable/cli/pip_lock/ ! Pip has been a flag bearer for Python packaging standards for some time now, so that alternatives can implement standards rather than copy behavior. So first a lock file standard had to be agreed upon which finally happened this year: https://peps.python.org/pep-0751/ https://peps.python.org/pep-0751/ Now it's a matter of a maintainer, who are currently all volunteers donating their spare time, to fully implement support. Progress is happening but it is a little slow because of this.
- domenkozar 11mo agoWhat if GitHub Actions were local-first and built using Nix (proper locking)? https://github.com/cachix/cloud.devenv.sh https://github.com/cachix/cloud.devenv.sh
- no_wizard 11mo agoHosted code on GitHub no less
- Group_B 11mo agoI was just writing about how crazy it is to use the third-party ssh tool https://broderic.blog/post/moving-away-from-netlify/ https://broderic.blog/post/moving-away-from-netlify/
- carschno 11mo agoIt 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 those who can still escape the lock-in, this is probably a good occasion to point to Forgejo, an open-source alternative that also has CI actions: https://forgejo.org/2023-02-27-forgejo-actions/ https://forgejo.org/2023-02-27-forgejo-actions/ It is used by Codeberg: https://codeberg.org/ https://codeberg.org/
- mfenniak 11mo agoOn 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.
- carschno 11mo agoGood point, also to illustrate that open-source is not a panacea. It merely holds a higher potential for certain issues to be fixed/improved than.
- esafak 11mo agoI don't know why they basically copied GHA.
- zufallsheld 11mo agoAFAIK because "act", the tool to run github actions locally, was there and there was no need to create something else. Also makes it easier for people to switch from github. Also see https://docs.gitea.com/usage/actions/design https://docs.gitea.com/usage/actions/design
- OptionOfT 11mo agoThe container manager is horrible. 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.
- jnwatson 11mo agoI committed the project I maintain to GitHub Actions when Actions first came out, and I'm really starting to regret it. 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.
- esafak 11mo agorenovatebot and dependabot can take care of that. Setting up CI is progress, nothing to regret.
- btown 11mo agoHas anyone built a “deep fork” tool that lets you make a private fork of all dependencies, then modifies their transitive dependencies to point to private forks, and so on? Ideally in a way where updates can be pulled in manually? Seems feasible.
- gwbas1c 11mo ago> Has anyone built a “deep fork” tool that lets you make a private fork of all dependencies, then modifies their transitive dependencies to point to private forks, and so on? Ideally in a way where updates can be pulled in manually? Seems feasible. If you do, please submit a "show HN." I'd love to use it.
- figmert 11mo agoA lot of the actions people tend to use are just unnecessary. They're simple wrappers around real tools. In those cases, use mise-en-place. It's a single action that installs all relevant tools (and keeps your local dev env in check), and it supports lock files.
- RSHEPP 11mo agoThis right here - I am migrating all of our GHA to use the mise action. Makes keeping the version of Go, linters, formatters etc. for the project so much easier. Haven't added the mise.lock yet, but on the list. Now getting my small team of devs to try using mise is much harder.
- akvadrako 11mo agoAnd if not mise, just a Makefile, shell scripts or custom docker images. Then you can run and develop them locally. GitHub actions has some rough edges around caching, but all the packaging is totally unimportant and best avoided.
- curcbit 11mo agomicrosoft never changes
- DalekBaldwin 11mo agoI'm assuming the lockfile should be checked into the repo itself, which presents a bootstrapping problem if you have to run an action to create the lockfile in the first place. They may need to build proper support for running actions locally -- there is the third-party https://github.com/nektos/act https://github.com/nektos/act tool which might be a starting point, but that's mostly designed so you can debug actions without having to repeatedly push and rerun. Probably they'll need a separate mechanism to statically analyze actions without running them.
- nine_k 11mo agoGitHub has been showing its limitations for quite some time now, and this gives a chance to alternative code forges to rise to prominence. I hope that Codeberg will become more mainstream for FOSS projects. I hope another competent player, beside GitLab and Bitbucket, will emerge in the corporate paid space.
- timwis 11mo agoReally compelling article! What do folks use instead in 2025?
- alex-ross 11mo agoThe lack of lockfiles is wild. Every other package manager figured this out years ago. Has anyone been bitten by a breaking change from an action update mid-pipeline?
- naikrovek 11mo agoMid-pipeline? No, but midday, oh yeah.
- michaelmior 11mo ago> You trust GitHub to give you the right code for a SHA. The vast majority of users use GitHub-hosted runners. If you don't trust GitHub, you have bigger problems than whether the correct code for an action is downloaded.
- gwbas1c 11mo agoI assume that git (not Github) verifies that, if you checkout a hash, the contents of the commit match the hash. Anyway, software is so complicated that at some level, you need to trust something because it's impossible to personally comprehend and audit all code. So, you still need to trust git. You still need to trust your OS. You still need to trust the hardware. You just don't have enough minutes in your life to go down through all those levels and understand it well enough to know that there's nothing malicious in there.
- eYrKEC2 11mo agoHas anyone used ArgoCD as a CI pipeline?
- sharts 11mo agoComplaining about GHA is like complaining that dog poop smells. Like, what did one expect?
- rurban 11mo agoI agree that github actions has a horrible syntax and can do much less than travis, appveyor, circle, ... I'd really have to resort to yaml references to do anything elegant. But yaml references aren't elegant at all. But it still is free and vastly outperforms the other free CI's. I just converted our old parrot travis runners to github actions. There I had constant troubles with travis timeouts of 15m 10 years ago. With the new github actions I can run the full tests (which was not possible with travis) in 3 minutes. About 8x faster hardware.