5 ms·

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

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

choeger 4y ago
I don't consider myself a cynic (1), but I am forced to pull that into questioning every time I see how many paid worker minutes are wasted by such endless streams of pull request modifications. (1) Who am I kidding, of course I am a cynic.
reubenmorais 4y ago
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 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.
- dwightgunning 4y ago
  Can you elaborate with some examples of workflows that it is incapable of? 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.
  - Benjamin_Dobell 4y ago
    Workflows that interact with the Github API heavily will fail as they're not available in act e.g. actions like https://github.com/styfle/cancel-workflow-action https://github.com/styfle/cancel-workflow-action. Dealing with secrets is also a bit cumbersome. You can throw the following on actions that are not compatible with act in order to skip them: if: ${{ !env.ACT }} That said, despite its limitations, I've been using both act and tmate in combination for a couple of years. Gets the job done.
    - dwightgunning 4y ago
      That’s a great example and suggestion. Thank you!
tjpnz 4y ago
I normally create a draft PR first to test CI/CD changes and open a new one when it's working. The workflow still sucks but I at least look like less of an idiot in the eyes of my peers.
- jaxn 4y ago
  Once I even had to hard fork our entire monorepo to refactor the release actions that tag main.
- fgeiger 4y ago
  I got you covered: I try out changes to CI tasks in a clone of the repository. Nobody needs to be bothered by my commits in the actual repository.
goodpoint 4y ago
It's ridiculous how we still tolerate the CI vendor lock-in.
- naikrovek 4y ago
  name one (1) CI system, open or closed, which shares enough with another CI system, open or closed, that there is no pain when changing from one to another. they are all at least semi proprietary.
  - speed_spread 4y ago
    All I ask from a CI is to be able to run Docker and access build resources in a structured manner. Concourse, Circle CI and gitlab do that.
    - naikrovek 4y ago
      so can GitHub Actions. And Jenkins, I guess. And running your jobs in Docker is what I recommend that people at my work do, and I admin several GitHub Enterprise Server instances and GitHub Enterprise Cloud as well. This is the one thing that Drone got very right - every Drone job runs in a container. It is built in to the drone tooling to be able to run those jobs locally on your development machine as well, and requiring containers is why that works. If you run your CI and/or CD steps from within a container, you can run that container anywhere, and writing a small script to read your CI/CD yaml (or whatever you use), and wrap your favorite container command line tool into a working local CI/CD system should be pretty trivial. Using containers also makes moving to another CI/CD system which can use containers as trivial as it can currently be.

choeger 4y ago

I don't consider myself a cynic (1), but I am forced to pull that into questioning every time I see how many paid worker minutes are wasted by such endless streams of pull request modifications. (1) Who am I kidding, of course I am a cynic.

reubenmorais 4y ago

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 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.

dwightgunning 4y ago
Can you elaborate with some examples of workflows that it is incapable of? 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.
- Benjamin_Dobell 4y ago
  Workflows that interact with the Github API heavily will fail as they're not available in act e.g. actions like https://github.com/styfle/cancel-workflow-action https://github.com/styfle/cancel-workflow-action. Dealing with secrets is also a bit cumbersome. You can throw the following on actions that are not compatible with act in order to skip them: if: ${{ !env.ACT }} That said, despite its limitations, I've been using both act and tmate in combination for a couple of years. Gets the job done.
  - dwightgunning 4y ago
    That’s a great example and suggestion. Thank you!

tjpnz 4y ago

I normally create a draft PR first to test CI/CD changes and open a new one when it's working. The workflow still sucks but I at least look like less of an idiot in the eyes of my peers.

jaxn 4y ago
Once I even had to hard fork our entire monorepo to refactor the release actions that tag main.
fgeiger 4y ago
I got you covered: I try out changes to CI tasks in a clone of the repository. Nobody needs to be bothered by my commits in the actual repository.

goodpoint 4y ago

It's ridiculous how we still tolerate the CI vendor lock-in.

naikrovek 4y ago
name one (1) CI system, open or closed, which shares enough with another CI system, open or closed, that there is no pain when changing from one to another. they are all at least semi proprietary.
- speed_spread 4y ago
  All I ask from a CI is to be able to run Docker and access build resources in a structured manner. Concourse, Circle CI and gitlab do that.
  - naikrovek 4y ago
    so can GitHub Actions. And Jenkins, I guess. And running your jobs in Docker is what I recommend that people at my work do, and I admin several GitHub Enterprise Server instances and GitHub Enterprise Cloud as well. This is the one thing that Drone got very right - every Drone job runs in a container. It is built in to the drone tooling to be able to run those jobs locally on your development machine as well, and requiring containers is why that works. If you run your CI and/or CD steps from within a container, you can run that container anywhere, and writing a small script to read your CI/CD yaml (or whatever you use), and wrap your favorite container command line tool into a working local CI/CD system should be pretty trivial. Using containers also makes moving to another CI/CD system which can use containers as trivial as it can currently be.