At Our World In Data we ended up using Buildkite to run custom CI jobs, integrated with GitHub, but on cheap, massive Hetzner machines. I can really recommend the experience!
The Pain That Is GitHub Actions
71–80 of 584 posts
Re: The Pain That Is GitHub Actions
#72I wonder if the complexity of fixing trivial code mistakes in CI is worth it compared to catching them in a pre-commit hook.
Unfortunately people will use --no-verify to bypass hooks.
There's a long set of steps to making a tool mandatory in a development environment, but the final step should always, always be, "And you will find yourself on a PIP if you refuse to use the mandatory tools."
If people want to die on a hill that is demonstrably causing problems for all of their coworkers then let em.
Re: The Pain That Is GitHub Actions
#73We recently had a developer -- while trying to debug container builds for a version upgrade for a PR on their local branch -- accidentally trigger a deployment of their local branch's docker container to production (!) while messing around with Github action workflow files in their pull request (not main). Outside of locking down edit access to the .github workflow yml files I'm not sure how vulnerabilities like this…
Yeah it's a difficult problem, templates help, then put the templates into another repo that is managed by a specific person and imported into others. Not sure how that work in a monorepo, I expect those controls wouldn't.
The problem is it's still possible to work around those controls unless you create some YAML monstrosity that stops people from making the mistake in the first place.
Re: The Pain That Is GitHub Actions
#74tldr but: don't use GitHub Actions. Its a mess, the availability is often atrocious, and the UI around it is _still_ as clunky as when they first rolled it out many years ago. There are better solutions out there.
GitHub Actions is like Microsoft Teams. Nobody who knows better wants to use it, but it's slightly better than what most did before (email/jenkins/nothing) and came with the thing you're already using. At least your boss thinks it's better. And it's such a good deal!
Does anyone think GHA is better than Jenkins?
I was doing things more than 20 years ago in Hudson that GHA can't do now.
Re: The Pain That Is GitHub Actions
#75I don't get the obsession with YAML and making things declarative that really should not be declarative. I'm so much happier on projects where I can use the non-declarative Jenkins pipelines instead of GH Actions or BB pipelines. These YAML pipelines are bad enough on their own, but throw in a department that is gatekeeping them and use runners as powerful as my Raspberry Pi and you have a situation where a lot of de…
I haven't tried to step through Scons, so that may be a system that looks like how I want it to look but fails entirely to deliver on its promises for all I know.
I think there's a place for making a builder that looks imperative, but can work out a tree of actions and run them. Gulp is a little bit this way, but again I haven't tried to breakpoint through it either.
If the next evolution in DevEx is not caring about what your code looks like in a stepping debugger, then the one after it will be. Making libraries that present a tight demo app for the Readme.md file and then are impossible to do anything tricky with or god forbid debug just needs to fucking stop. Yesterday. And declarative systems are almost always the worst.
Re: The Pain That Is GitHub Actions
#76Whenever I get mad at GitHub Actions, I refer to it by it's true name: VisualSourceSafe Actions. Because that's what it is, and it shows. If you check out their Action Runner's source code[1], you'll find the VSS prefix all over, showing it's lineage. [1] https://github.com/actions/runner/blob/6654f6b3ded8463331fb0...
I know they've fixed VSS ages ago, but for many years it was buggy af and would catastrophically lose data on automerges that it confidently made and was wrong.
I had a coworker who called it Visual Sorta-Safe which is just about the best parody name I've ever heard in my entire career.
Re: The Pain That Is GitHub Actions
#77Earlier quoted context omitted.
Glad I’m not the only one. GitLab runners just make sense to me. A container you run scripts in. I have some GitHub actions for some side projects and it just seems so much more confusing to setup for some reason.
Actions have special integration with GitHub (e.g. they can annotate the pull request review UI) using an API. If you forgo that integration, then you can absolutely use GitHub Actions like "a container you run scripts in." This is the advice that is usually given in every thread about GitHub Actions.
Devil's advocate: They could make the github CLI capable of doing all of those things (if it's not already), and then the only thing the container needs is a token.
Re: The Pain That Is GitHub Actions
#78Earlier quoted context omitted.
Unfortunately people will use --no-verify to bypass hooks.
There's a long set of steps to making a tool mandatory in a development environment, but the final step should always, always be, "And you will find yourself on a PIP if you refuse to use the mandatory tools." If people want to die on a hill that is demonstrably causing problems for all of their coworkers then let em.
Oh how I wish engineering leadership would actually mandate certain things such as this.
Re: The Pain That Is GitHub Actions
#79Earlier quoted context omitted.
Glad I’m not the only one. GitLab runners just make sense to me. A container you run scripts in. I have some GitHub actions for some side projects and it just seems so much more confusing to setup for some reason.
So Github was really the perfect acquisation for the Microsoft portfolio. Applications with a big market share that are technically inferior to the competition. // Luckily still a gitlab user, but recently forced to Microsoft Teams and office.
Technical superiority is so irrelevant compared to distribution. Welcome to capitalism, where the market rewards marketing.
Re: The Pain That Is GitHub Actions
#80I worked at companies using Gitlab for a decade, and got familiar with runners. Recently switched to a company using Github, and assumed I'd be blown away by their offering because of their size. Well, I was, but not in the way I'd hoped. They're absolutely awful in comparison, and I'm beyond confused how it got to that state. If I were running a company and had to choose between the two, I'd pick Gitlab every time j…
Glad I’m not the only one. GitLab runners just make sense to me. A container you run scripts in. I have some GitHub actions for some side projects and it just seems so much more confusing to setup for some reason.
There are lots of problems.
Actions try to abstract the script away and give you a consistent experience and, must crucially, allow sharing. Because gitlab has no real way to share actions or workflows (I can do yaml include, but come on that sucks even harder than actions) you are constantly reinventing the wheel.
That's ok if all you do is " build folder" but if you need caching, reporting of issues, code coverage etc. Pp it gets real ugly really fast.
Example: yesterday I tried services, i.e. starting up some DB and backend containers to run integration tests against. Unfortunately, you cannot expand dynamic variables (set by previous containers) but are limited to already set bars. So back to docker compose...and the gitlab pipelines are chock full of such weird limitations