21–30 of 161 posts
Earlier quoted context omitted.
yeah i also use other incredibly informative messages like: - oh oops - fix for real this time - will this actually work? - this probably won't fix it - a
Yeah, but with one word messages you can pass it on the command line without quotes: git commit . -m fix
Somebody wants to build a serverless- type ci system?
I also struggle with CI vendor lock-in. Somebody wants to build a serverless- type ci system?
Finally! I've been wanting something like this for ages- generally speaking I don't consider myself an idiot, but I'm forced to pull that into questioning every time I test and debug ci/cd actions with an endless stream of pull request modifications
Finally! I've been wanting something like this for ages- generally speaking I don't consider myself an idiot, but I'm forced to pull that into questioning every time I test and debug ci/cd actions with an endless stream of pull request modifications
Unfortunately act is only capable of running very simple workflows. I've found this action to be more useful against the endless PR stream: https://github.com/mxschmitt/action-tmate You drop it in your workflow and get an SSH shell into the worker, figure things out iteratively, then push when it's working.
So far I’ve not found any limitations or issues using Ubuntu runners on my OSX dev machine. A couple examples from my workflows: - building docker images - provisioning VMs with the Digital Ocean cli / http api - hardening VMs with ansible - creating/managing k3s clusters with k3sup - deploying apps with helm
I like your suggested approach of using tmate to access the worker mid-way through a run. This should make it faster to develop/debug the steps that make up the workflow. Though this doesn’t address the cycle time of push-to-GitHub/queue-workflow/watch-for-result.
I’m actually going to try combining the two techniques - use tmate to develop inside a local act runner.
I also struggle with CI vendor lock-in. Somebody wants to build a serverless- type ci system?
[1]: https://dagger.io/
[2]: https://earthly.dev/
I’ve used this a bunch; I actually don’t know how else you’d write and test a GitHub action. Do people just push them and hope they work and push more commits with “fix” as the message until it works?