71–80 of 137 posts
Earlier quoted context omitted.
How's Jenkins looking these days?
Seems fine to me, I don't really understand why people think CI is hard and they need to shop a different platform. All these systems are is a glorified shell script runner. It seems like developers just keep making up new DSLs over and over to do the same things.
I’ve been bedeviled by arm/intel/Mac issues with this. I want to be able to use this project, I really do. But it’s just not yet there, and this isn’t on Nektos. Nektos is, as best I understand it, trying to approximate GHA, but it’s not easy.
I've seen (but not used) this tool recently, which seems like it does a similar thing. Curious if it is any better experience. https://github.com/bahdotsh/wrkflw
Dumb question, but why hasn’t GitHub made a solution that lets you run GitHub Actions locally? Or at the very least a solution that validates the action (giving a bit more certainty that it will succeed, a bit like a dry-run)? (My war story:) I stopped using GHAs after an optimistic attempt to save myself five key strokes ‘r’ ‘s’ ‘p’ ‘e’ ‘c’ led to 40+ commits and seeing the sunrise but still no successful test run v…
Like https://docs.gitlab.com/runner/ ?
Pour one out, I guess, but it's okay since I previously was super angry at it for languishing in the uncanny valley of "hello world works, practically nothing else does" -- more or less like nektos/act and its bazillions of forks
Earlier quoted context omitted.
AWS Lambda publishes Docker images (e.g. public.ecr.aws/lambda/python:3.12-arm64), does Github Actions have something similar?
https://github.com/actions/runner-images
If you may say "but, why?!" it's because I really wanted to know what versions of everything I could expect in GHA, and I detest "git commit -amdummy && git push" stupidity so I guess the answer is "because I'm wired that way"
This is annoying when the code you write is native or reaches out to native stuff. Then all of the sudden your container that builds perfectly on the Mac doesn't build on Linux anymore. (and vice versa, looking at you gcc on debian).
GitHub just (January) got Linux ARM runners, but they're not available for private customers yet.
And their Mac runners do not come with Docker, and it cannot be installed.
GitHub really needs to support local development with GitHub actions. Sheesh. What a step backwards.
I've had the displeasure of working with Macs on which we wrote code that would end up being a docker container. But what is compiled on a Mac is an aarch64 container. What is compiled on an AMD64 Linux machine is amd64. This is annoying when the code you write is native or reaches out to native stuff. Then all of the sudden your container that builds perfectly on the Mac doesn't build on Linux anymore. (and vice ver…
Rather than tying CI & deployments to Github Actions, it is usually better to pull as much of it as possible out to shell scripts and call them in containers in GH actions.. There are optimizations you’ll want (caching downloaded dependencies etc); if you wait to make those after your build is CI-agnostic you’ll be less tempted by vendor specific shortcuts. Usually means more code - but, easier to test locally. Also,…
- You may need something to connect the dots between code changes and containers. It's not always possible to build everything on every change, especially in a multi/mono-repo setup.
- You probably need some way to connect container outcomes back to branch protection rules. Again, if you are building everything, every time, it's pretty simple, but less so otherwise.
- You likely want to have some control over the compute capacity on which the actions run, both for speed and cost control. And since caching matters, some compute solutions are better than others.
I don't think GitHub Actions solves any of these problems well, but neither do containers on their own.
Just this week I tried giving this another chance to debug some weird CI failures for ruby tests. I’m on M-series macs so there is an inherent platform mismatch. That coupled with us using depot images as action runners. I was never able to get it running past the dry-run stage. There is just a lot of differences between CI runners and my local docker images. I even gave the image from catthehacker a try. Which is li…
Sounds similar to my own experiences trying to debug GH actions locally. I've tried twice now to get it working, pulling down many GBs of images and installing stuff and then getting stuck in some obscure configuration or environment issue. I was even running Linux locally which I figured would be the happiest path. I'm not eager to try again, and unless there's a CI that's very slow or GH actions that need to be upd…
I've had the displeasure of working with Macs on which we wrote code that would end up being a docker container. But what is compiled on a Mac is an aarch64 container. What is compiled on an AMD64 Linux machine is amd64. This is annoying when the code you write is native or reaches out to native stuff. Then all of the sudden your container that builds perfectly on the Mac doesn't build on Linux anymore. (and vice ver…
Match dev env to prod env?