21–30 of 137 posts
My alternative was to have a dedicated repository where I can spam the Git and workflow run histories as much as I need to experiment with workflows.
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…
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 updated often for some reason, I feel like it's better to just brute-force it - waiting for CI to run remotely.
WARNING: act is great if you use docker. Act does not support podman. Issues or discussions related to providing support/coverage/compatibility/workarounds for podman are closed with a terse message. Unusual for an open source project.
It's important to note that this tool does not use the same container images or runtime environment that GitHub Actions actually runs. It's an approximation. For simple use cases that won't matter, but if you have complex GitHub Actions you're bound to find varying behavior. That can lead to frustration when you're debugging bizarre CI failures.
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 wonder if there is a proposal to support code-based actions. Config-based CI needs to die.
I try to do as much as possible in a (dagger) script and use the GHA to call it. That way I can test the script locally. I wonder if there is a proposal to support code-based actions. Config-based CI needs to die.
I try to do as much as possible in a (dagger) script and use the GHA to call it. That way I can test the script locally. I wonder if there is a proposal to support code-based actions. Config-based CI needs to die.
Why dagger and not just... any language? (Nushell for example https://www.nushell.sh/ )
nu is my default shell. Note that I am not talking about dagger shell. https://dagger.io/blog/a-shell-for-the-container-age-introdu...