Live data from Hacker News

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

nesbitt.io

121–130 of 267 posts

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

#122
post #104

Earlier quoted context omitted.

So it’s a workspace that includes changes from multiple branches at once, like `jj new revset-1 revset-2 revset-3 …` ? (Git has octopus merges, jj just calls them “merge commits” even though they may have more than two parents)

Don't remember exactly. If I think about it, it could be quite complex. Git has the concept of "atomic repos." Repos are a single unit, including all files, branches, tags, etc. Older systems basically had a single repo, with "lenses" into sections of the repo (usually called "workspaces," or somesuch. VSS called them something else, but I can't remember). I find the atomic repo thing awkward; especially wrt librarie…

a repo is a repo - you're describing what is nowadays known as a 'monorepo' and it's a perfectly reasonable and desirable even exactly for the reasons you mention, except the 'distributed' part makes it very inconvenient to handle on dev boxes if it grows a lot.

in a centralized VCS there are viable CICD options like 'check the compiler binaries in' or even 'check the whole builder OS image in' which git is simply not able to handle by design and needs extensions to work around deficiencies. git winning the mindshare battle made these a bit forgotten, but they were industry standard a couple decades ago.

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

#123
post #120

Earlier quoted context omitted.

Don't remember exactly. If I think about it, it could be quite complex. Git has the concept of "atomic repos." Repos are a single unit, including all files, branches, tags, etc. Older systems basically had a single repo, with "lenses" into sections of the repo (usually called "workspaces," or somesuch. VSS called them something else, but I can't remember). I find the atomic repo thing awkward; especially wrt librarie…

Your workflow is fascinating! What languages do you work in, if you don’t mind me asking? Both git and jj have sparse checkouts these days, it sounds like you’d be into that Do you vendor the libraries you use? Python packages typically don’t include the testing or docs in wheels uploaded to PyPI, for instance These days in Pythonland, it’s typical to use a package manager with a lockfile that enforces build reproduc…

I work mostly in Swift (native Apple apps). Most of my libraries are Swift Package Manager modules.

You can see most of my stuff in GH. You need to look at the organizations, as opposed to my personal repos: https://github.com/ChrisMarshallNY#browse-away

Thanks for the heads-up. I'll give it a gander.

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

#124

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…

> unless they put the money where their mouth is, it's just noise I used to work for a Japanese company, and one of their core philosophies was “Don’t complain, unless you have a solution.” In my experience, this did not always have optimal outcomes: https://littlegreenviper.com/problems-and-solutions/

My favorite retort to that is, "I don't have to know how to fix it to know my arm is broken."

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

#125
post #99

Earlier quoted context omitted.

I tried to use CircleCI and I gotta say, it is absolutely not better than GitHub Actions…

I have also used Travis. Ditto. Github Actions is actually one of the better CI options out there, even if on an absolute scale it is still pretty bad. As far as I can tell nobody has made a CI system that is actually good .

JetBrains TeamCity is pretty good IMHO

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

#126

Earlier quoted context omitted.

> unless they put the money where their mouth is, it's just noise I used to work for a Japanese company, and one of their core philosophies was “Don’t complain, unless you have a solution.” In my experience, this did not always have optimal outcomes: https://littlegreenviper.com/problems-and-solutions/

My favorite retort to that is, "I don't have to know how to fix it to know my arm is broken."

Stealing it...

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

#127
post #96

Earlier quoted context omitted.

I won't "defend" Microsoft in this case, but I am always annoyed by phrases like "world's biggest billion-dollar businesses... bablah". Their size or past misbehaviors shouldn't be relevant to this discussion. Bringing those up feels a bit like an ad hominem. Whether criticism is valid should depend entirely on how GitHub Actions actually works and how it compares to similar services.

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.

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

#128
post #8

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

Because for some reason they use the same system to do releases and sign them and publish them.

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

#129
post #57
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…

> 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

There's a repository setting you can enable to prevent actions from running unless they have their version pinned to a SHA digest. This setting applies transitively, so while you can't force your dependencies to use SHA pinning for their dependencies, you can block any workflow from running if it doesn't.
Post reply on HN