Run 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
GitHub Actions has a package manager, and it might be the worst
81–90 of 267 posts
Re: GitHub Actions has a package manager, and it might be the worst
#82See 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".
Re: GitHub Actions has a package manager, and it might be the worst
#83> 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 woul…
> 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. CI/CD does not exist in the vacuu…
You seem to be talking mostly about the CD part. Some thoughts:
On the one hand, CD workflows are less exposed than CI workflows. You only deploy code that has made it through your review and CI processes. In a non-continuous deployment model, you only deploy code when you decide to. You are not running your CD workflow on a third-party pull request.
On the other hand, the actual CD permission is a big deal. If you leak a credential that can deploy to your k8s cluster, you are very, very pwned. Possibly in a manner that is extremely complex to recover from.
I also admit that I find it rather surprising that so many workflows have a push model of deployment like this. My intuition for how to design a CD-style system would be:
1. A release is tagged in source control.
2. Something consumes that release tag and produces a production artifact. This might be some sort of runner that checks out the tagged release, builds it, and produces a ghcr image. Bonus points if that process is cleanly reproducible and more bonus points if there's also an attestation that the release artifact matches the specified tag and all the build environment inputs. (I think that GitHub Actions can do this, other than the bonus points, without any secrets.)
3. Something tells production to update to the new artifact. Ideally this would trigger some kind of staged deployment. Maybe it's continuous, maybe it needs manual triggering. I think that, in many production systems, this could be a message from the earlier stages that tells an agent with production privileges to download and update. It really shouldn't be that hard to make a little agent in k8s or whatever that listens to an API call from a system like GitHub Actions, authenticates it using OIDC, and follows its deployment instructions.
P.S. An attested-reproducible CD build system might be an interesting startup idea.
Re: GitHub Actions has a package manager, and it might be the worst
#84I'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 aga…
> 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)
Re: GitHub Actions has a package manager, and it might be the worst
#85Earlier quoted context omitted.
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.
Re: GitHub Actions has a package manager, and it might be the worst
#86What’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.
Everyone is free to use alternative CI/CD workflow pipelines. These are often better than Github Actions. These include - https://circleci.com/ - https://www.travis-ci.com/ - 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 i…
I'm a huge fan of: https://onedev.io/ it might not the best, but it's fast it and does it's job!
Re: GitHub Actions has a package manager, and it might be the worst
#87To get something of a lockfile you can use the hash of the version you want to pin your dependencies: > actions/checkout@f43a0e5ff2bd294095638e18286ca9a3d1956744
Transitive dependencies?
Yeah, only works if all used Actions would use SHAs too, which is not the case.
Positive example: https://github.com/codecov/codecov-action/blob/96b38e9e60ee6... Negative example: https://github.com/armbian/build/blob/54808ecff253fb71615161...
Re: GitHub Actions has a package manager, and it might be the worst
#88What’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.
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.
Re: GitHub Actions has a package manager, and it might be the worst
#89Earlier quoted context omitted.
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.
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...
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”.
Re: GitHub Actions has a package manager, and it might be the worst
#90Earlier quoted context omitted.
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
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.