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.
GitHub Actions has a package manager, and it might be the worst
151–160 of 267 posts
Re: GitHub Actions has a package manager, and it might be the worst
#152A 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.
Re: GitHub Actions has a package manager, and it might be the worst
#153Earlier quoted context omitted.
CI shouldn't do deployments, deployment pipelines should run separately when a new release passes CI Of course the general purpose task runner that both run on does need to support secrets
you conveniently ignored the "CD" part of CI/CD
As mentioned by sibling comments, these two parts are very different. GHA and alternatives are primarily for CI; many people choose to use it solely for CI. For these reasons I did ignore CD.
Re: GitHub Actions has a package manager, and it might be the worst
#154Earlier quoted context omitted.
You actually don’t need (long-lived / hard-coded) secrets in this scenario if you use OIDC: https://docs.github.com/en/actions/how-tos/secure-your-work/...
Technically yes. It depends on whether you consider the account ID to be a secret or not (AWS say "sensitive but not secret" which doesn't help much). But also it can make sense to treat all environment variables as secrets by default just so you don't accidentally end up putting something somewhere that turns out to have been Wrong.
GP is saying that GHA would need zero information about AWS if CodeBuild used a Github token and listened for GHA runs.
Re: GitHub Actions has a package manager, and it might be the worst
#155Normally 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…
It'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 liv…
I 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
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.
- GitHub's free component honestly hurts itself here. I don't have to care about waste if it's mostly free anyways.
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.
Re: GitHub Actions has a package manager, and it might be the worst
#156What’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.
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.
Re: GitHub Actions has a package manager, and it might be the worst
#157Earlier quoted context omitted.
CI is arguable, but how do you intend to do deployments with no secrets?
The secret is held by the metadata server that the CI instance has access to Or: the deployment service knows the identity of the instance, so its secret is its private key Or, how PyPI does it: the deployment service coordinates with the trusted CI/CD service to learn the identity of the machine (like its IP address, or a trusted assertion of which repository it’s running on), so the secret is handled in however tha…
> The secret is held by the metadata server that the CI instance has access to
But how does the metadata server know that the CI instance is allowed to access the secret? Especially when the CI/CD system is hosted at a 3rd. party. It needs to present some form of credentials. The CI system may also need permission or credentials for a private repository of packages or artifacts needed in the build process.
For me, a CI/CD system needs two things: Secret management and the ability to run Bash.
Re: GitHub Actions has a package manager, and it might be the worst
#158Earlier quoted context omitted.
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 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.
Re: GitHub Actions has a package manager, and it might be the worst
#159What’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.
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`.
Re: GitHub Actions has a package manager, and it might be the worst
#160Earlier quoted context omitted.
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.