For all its faults I still like actions. I have always kept it simple, tests, docker builds, pushing images post build. It’s not perfect but’s quite nice for something baked into GitHub. Never used Buildkite but the immediate blocker for me is I don’t want to spend $30/month per seat for a build tool.
GitHub Actions is slowly killing engineering teams
151–160 of 219 posts
Re: GitHub Actions is slowly killing engineering teams
#152Controversial opinion: GitHub actions are good enough.
I have one job that runs a shell script that runs tests, a second one that builds and pushes the docker image, and a third one that triggers CD.
Could it be faster? Yes. Could the log viewer be better? Yes. Could the configuration file format be better? Yes. Could the credentials work better? Yes.
However they're well integrated with GitHub (including GHCR), work well and are affordable.
Re: GitHub Actions is slowly killing engineering teams
#153Earlier quoted context omitted.
Can you explain how your product solves this problem? I clicked around your site and couldn't figure it out.
As a (very happy) RWX customer: - Intermediate tasks are cached in a docker-like manner (content-addressed by filesystem and environment). Tasks in a CI pipeline build on previous ones by applying the filesystem of dependent tasks (AFAIU via overlayfs), so you don't execute the same task twice. The most prominent example of this is a feature branch that is up-to-date with main passes CI on main as soon as it's merged…
The previous post describes a problem where you do a large docker build, then fan out to many jobs which need to pull this image, and the overhead is enormous. This implies rwx has less overhead. Just saying that there’s content addressable cache doesn’t explain how this particular problem is solved.
If you have a dockerfile where you make a small change in your source results in one particular very large layer that has to be built, then you want to fan out and run many parallel tests using that image, what actually happens when you try to run that new fat layer on a bunch of compute, and how is it better than the implied naive solution? That fat layer exists on a storage system somewhere, and a bunch of computer nodes need to read it, what happens?
Re: GitHub Actions is slowly killing engineering teams
#154To be honest, GitHub actions made a big impact at a time when every other CI framework sucked, really badly. Maybe today, others are much better than they used to be!
Re: GitHub Actions is slowly killing engineering teams
#155YMMV, of course. I set up our actions pipeline four years ago and basically never have to worry or even think about it. The UI isn't perfect, but it's good enough.
Our scenario: relatively simple monorepo, lots of docker, just enough bash, trunk-based dev strategy. It's great for that.
Re: GitHub Actions is slowly killing engineering teams
#156Earlier quoted context omitted.
JSON or YAML imply a buildkite DSL as there's no standard JSON or YAML format for build scripts
I assume by DSL they mean some custom templating language built on top, for things like iterating and if-conditions. If it's plain JSON/YAML you can produce that using any language you wish.
I don't think you understood it yet: the JSON or YAML is a DSL
Re: GitHub Actions is slowly killing engineering teams
#157Earlier quoted context omitted.
Make is incredibly cursed. My favorite example is it having a built-in rule (oversimplified, some extra Makefile code that is pretended to exist in every Makefile) that will extract files from a version control system. https://www.gnu.org/software/make/manual/html_node/Catalogue... What you're saying is essentially ”Just Write Bash Scripts”, but with an extra layer of insanity on top. I hate it when I encounter a pro…
https://github.com/casey/just is an uncursed make (for task running purposes - it's not a general build system)
How does `just` compare to Task (https://taskfile.dev/)?
Re: GitHub Actions is slowly killing engineering teams
#158Earlier quoted context omitted.
What pains are you experiencing? Cdk has far exceeded Ansible and Terraform in my experience.
Hooo boy where do I begin? Dependency deadlocks are the big one - you try to share resource attributes (eg ARN) from one stack to another. You remove the consumer and go to deploy again. The producer sees no more dependency so it prunes the export. But it can't delete the export, cause the consumer still needs it. You can't deploy the consumer, because the producer has to deploy first sequentially. And if you can't d…
> The producer sees no more dependency so it prunes the export. But it can't delete the export, cause the consumer still needs it. You can't deploy the consumer, because the producer has to deploy first sequentially. And if you can't delete the consumer (eg your company mandates a CI pipeline deploy for everything) you gotta go bug Ops on slack, wait for someone who has the right perms to delete it, then redeploy.
This is a tricky issue. Here is how we fixed it:
Assume you have a stack with the ConstructID of `foo-bar`, and that uses resources exported to `charlie`.
Update the Stack ConstructID to be a new value, ie `foo-bar-2`. Then at the very end of your CI, add a `cdk destroy foo-bar` to delete the original stack. This forces a new deployment of your stack, which has new references. Then, `charlie` updates with the new stack and the original `foo-bar` stack can be safely destroyed once `charlie` successfully updates.
The real conundrum is with data - you typically want any data stacks (Dynamo, RDS, etc) to be in their own stack at the very beginning of your dependency tree. That way any revised stacks can be cleanly destroyed and recreated without impacting your data.
Re: GitHub Actions is slowly killing engineering teams
#159[dead]
Re: GitHub Actions is slowly killing engineering teams
#160Controversial opinion: GitHub actions are good enough. I have one job that runs a shell script that runs tests, a second one that builds and pushes the docker image, and a third one that triggers CD. Could it be faster? Yes. Could the log viewer be better? Yes. Could the configuration file format be better? Yes. Could the credentials work better? Yes. However they're well integrated with GitHub (including GHCR), work…
I basically agree.
But also, CI should be the last line of defense, not the first line.
If your system is not byzantine, you should be able to run almost all your tests locally and not need to boot a cloud machine that has to be setup from scratch and deal with all the overhead in your core loop.
Having a build system that knows what tests need to be run helps here since you're no longer just throwing compute at the problem.