Normally 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.
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 live with!
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
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.
By adding one file to your git repo, you get cross-platform build & test of your software that can run on every PR. If your code is open source, it's free(ish) too.
It feels like a weekend project that a couple people threw together and then has been held together by hope and prayers with more focus on scaling it than making it well designed.
I will say that SourceSafe had one advantage: You could create "composite" proxy workspaces.
You could add one or two files from one workspace, and a few from another, etc. The resulting "avatar" workspace would act like they were all in the same workspace. It was cool.
No, it let you continue to follow the main branch for most files, while files you edited would have their changes saved to a different location. And was just about as horrible as you might imagine.
We moved from VSS to SVN, and it took a little encouraging for the person who had set up our branching workflow using that VSS feature to be happy losing it if that freed us from VSS.
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 libraries. If I include a package, I get the whole kit & kaboodle; including test harnesses and whatnot. My libraries thend to have a lot more testing code than library code.
Also, I would love to create a "dependency repo," that aggregates the exported parts of the libraries that I'm including into my project, pinned at the required versions. I guess you could say package managers are that, but they are kind of a blunt instrument. Since I eat my own dog food, I'd like to be able to write changes into the dependency, and have them propagate back to their home repo, which I can sort of do now, if I make it a point to find the dependency checkout, make a change, then push that change, but it's awkward.
But that seems crazy complex (and dangerous), so I'm OK with the way things work now.
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 reproducibility and SHA signatures for package attestation. If you haven’t worked with tools like uv, you might like their concepts (or you might be immediately put off by their idea of hermetically isolated environments idk)
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.
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.