Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Actions has a package manager, and it might be the worst

nesbitt.io

Post reply on HN
Print view View original

251–260 of 267 posts

Re: GitHub Actions has a package manager, and it might be the worst

#251

Post by gwbas1c »

michaelmior wrote: post #226

> 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.

I 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.

Re: GitHub Actions has a package manager, and it might be the worst

#252

Post by notatallshaw »

IshKebab wrote: post #103

> The core problem is the lack of a lockfile. Every other package manager figured this out decades ago Well... not Pip!

We're getting there 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/

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.

Re: GitHub Actions has a package manager, and it might be the worst

#254

Post by [deleted] »

miohtama wrote: post #158
klausa wrote: post #53

Earlier quoted context omitted.

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.

[deleted]

Re: GitHub Actions has a package manager, and it might be the worst

#255

Post by ramon156 »

pjc50 wrote: post #36

This 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.

Lol 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

Re: GitHub Actions has a package manager, and it might be the worst

#256

Post by novok »

worldsayshi wrote: post #64

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.

After having to deal with shell rc files causing chaos and unpredictability, I can appreciate your top level code fundamental not being random code but something that is parsable and not subject to the halting problem.

Re: GitHub Actions has a package manager, and it might be the worst

#257

Post by zufallsheld »

esafak wrote: post #221
mfenniak wrote: post #142

Earlier quoted context omitted.

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.

I don't know why they basically copied GHA.

AFAIK 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

Re: GitHub Actions has a package manager, and it might be the worst

#258

Post by Griffinsauce »

csomar wrote: post #170
bloppe wrote: post #42

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…

Using an SHA is an anti-pattern for me. Because by using one, you kind of modeled "I am getting this fixed/static thing"; when in reality, it is very far from that. I got bitten by it twice that I learned that you either have a lock file or you don't.

Wait, can you explain how you _don't_ get a static thing from a SHA?

Re: GitHub Actions has a package manager, and it might be the worst

#259

Post by Griffinsauce »

CamouflagedKiwi wrote: post #45
miohtama wrote: post #30

Earlier 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'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 soft…

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)

Re: GitHub Actions has a package manager, and it might be the worst

#260

Post by CamouflagedKiwi »

olafmol wrote: post #138
CamouflagedKiwi wrote: post #45

Earlier quoted context omitted.

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 soft…

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.

To be clear, I do think CircleCI is a better product than GHA. I just think there's a lot of air sucked out of the room by GHA being available 'for free' and out of the box.

Also, honestly, I don't care about any of those features. The main thing I want is a CI system that is fast and customisable and that I don't have to spend a lot of time debugging. I think CircleCI is pretty decent in that regard (the "rerun with SSH" thing is way better than anything else I've seen) but it doesn't seem to be getting any better over time (e.g. caching is still very primitive and coarse-grained).

Post reply on HN