Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Act: Run your GitHub Actions locally

github.com

Post reply on HN
Print view View original

51–60 of 161 posts

Re: Act: Run your GitHub Actions locally

#51

Post by Benjamin_Dobell »

dwightgunning wrote: post #26
reubenmorais wrote: post #18

Earlier quoted context omitted.

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.

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…

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

Re: Act: Run your GitHub Actions locally

#52

Post by noroot »

zephyros wrote: post #29

I found Dagger[1] and Earthly[2] which supposedly would solve the issue of debugging the CI locally. I haven't got time to try them out yet though. [1]: https://dagger.io/ [2]: https://earthly.dev/

Yeah, I got so frustrated with the odd workflow (having no sane way to locally test new/more advanced pipelines and having to do lot's of "change .gitlab-ci commits") at work that I started investigating alternatives.

At home, for some hobby projects, I've been using earthly. It's just amazing. I can fully run the jobs locally and they are _blazing_ fast due to the buildkit caching. The CI now only just executes the earthly stuff and is super trivial (very little vendor lock in, I personally use woodpecker-ci, but it would only take 5 minutes to convert to use GH actions).

I am not a fan of the syntax. But it's so familiar from Dockerfiles and so easy to get started I can't really complain about it. Easy to make changes, even after months not touching it. Unless I update dependencies or somehow invalidate most of the cache a normal pipeline takes This workflow is such a game-changer. It also allows, fairly easy, to do very complicated flows [1].

I've tried to get started with dagger but I don't use the currently supported SDK's and the cue-lang setup was overwhelming. I think I like the idea of a more sane syntax from dagger, but Earthly's approachability [2] just rings true.

[1]: https://github.com/phoenixframework/phoenix/blob/master/Eart...

[2]: https://earthly.dev/blog/platform-values/#approachability

Re: Act: Run your GitHub Actions locally

#53

Post by dwightgunning »

Benjamin_Dobell wrote: post #51
dwightgunning wrote: post #26

Earlier quoted context omitted.

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…

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

That’s a great example and suggestion. Thank you!

Re: Act: Run your GitHub Actions locally

#54

Post by pindab0ter »

plonk wrote: post #16
pocketarc wrote: post #6

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?

I add a workflow like this: - write the main job in a Python/PowerShell/Bash script that runs locally, - write a workflow that sets up the environment (AWS login), installs dependencies (using GitHub's facilities for that) and calls the script (often passing values using GitHub Secrets), - push the workflow with a "push" trigger on a feature branch (for fast testing), - push 30 fixup commits to fix all the small synt…

> - push 30 fixup commits to fix all the small syntax errors, logic mistakes, and GHA idiosyncrasies I hadn't thought of,

I don't have a lot of experience with GitHub Actions, but is there really no better way to do this?

Re: Act: Run your GitHub Actions locally

#55

Post by toastal »

de_keyboard wrote: post #48
Arnavion wrote: post #33

Rather than replacing your Makefile with GH Actions, replace your GH Actions with a Makefile, and make your GH Actions run `make` in a script task. Do you really need that GH Action for pulling Docker images / installing $language_compiler / creating cloud resources ? A `docker` / `curl` / `sudo apt-get install` invocation in a Makefile / script needs to be written once and is the same in CI as on your dev machines.…

I agree. GitHub Actions should call your scripts but your scripts should not depend on GitHub Actions API. I also suggest Bazel as a consideration alongside Make. With Bazel, you get two advantages over Make: 1. It is easier to ensure that what GitHub Actions runs and builds is the same as what you have locally, since Bazel can fetch toolchains as part of the build process 2. Using a Bazel remote cache, you do not ha…

Same can be said about Nix and as a bonus you get Nix instead of Starlark

Re: Act: Run your GitHub Actions locally

#56

Post by plonk »

pindab0ter wrote: post #54
plonk wrote: post #16

Earlier quoted context omitted.

I add a workflow like this: - write the main job in a Python/PowerShell/Bash script that runs locally, - write a workflow that sets up the environment (AWS login), installs dependencies (using GitHub's facilities for that) and calls the script (often passing values using GitHub Secrets), - push the workflow with a "push" trigger on a feature branch (for fast testing), - push 30 fixup commits to fix all the small synt…

> - push 30 fixup commits to fix all the small syntax errors, logic mistakes, and GHA idiosyncrasies I hadn't thought of, I don't have a lot of experience with GitHub Actions, but is there really no better way to do this?

The only way to actually run the workflow is to push the code and trigger the workflow somehow. And you can't push code without committing it since this is git.

You could write the workflow correctly the first time. Good luck. It's not one language, you're writing PowerShell scripts inside a bunch of YAML files that reference each other with relative paths and need to call installers that were never written for unattended installs. The only way I can make it work is through trial and error.

GHA really feels like it's trying to cobble up a CI/CD pipeline from a million different pieces that were designed for entirely different purposes. It works, if you spend enough weeks on it, but it will never be pleasant to configure. I can understand why they didn't even try to make it reproducible on the users' workstations, it can break if basically any part of your system's configuration, filesystem, or environment deviates from the runners.

That's obviously not entirely GitHub's fault and the service is very practical once it's set up. My advice is to depend on GHA for their useful features (caching, Secrets, parallel jobs) and do everything else in your own scripts or in Docker.

Re: Act: Run your GitHub Actions locally

#57

Post by tvaughan »

Arnavion wrote: post #33

Rather than replacing your Makefile with GH Actions, replace your GH Actions with a Makefile, and make your GH Actions run `make` in a script task. Do you really need that GH Action for pulling Docker images / installing $language_compiler / creating cloud resources ? A `docker` / `curl` / `sudo apt-get install` invocation in a Makefile / script needs to be written once and is the same in CI as on your dev machines.…

This so hard. I like to think of the make targets, e.g. build, test, install, etc. as an API that should be consistent across repos. This really helps with cross team collaboration. The details of how these tasks happen is free to change at will without the need to “distribute” these changes to developers. There’s no disruption to anyone’s flow. Plus, with a little documentation, on boarding new developers is so much more simple.

Re: Act: Run your GitHub Actions locally

#58

Post by intelVISA »

Arnavion wrote: post #33

Rather than replacing your Makefile with GH Actions, replace your GH Actions with a Makefile, and make your GH Actions run `make` in a script task. Do you really need that GH Action for pulling Docker images / installing $language_compiler / creating cloud resources ? A `docker` / `curl` / `sudo apt-get install` invocation in a Makefile / script needs to be written once and is the same in CI as on your dev machines.…

I use Makefiles anywhere I can fit them they're a brief respite from YAML hell. This issue was solved in 1976 -- I appreciate there's a lot of VC money in reinventing the wheel (and coming full circle) but I digress.

Re: Act: Run your GitHub Actions locally

#59

Post by intelVISA »

toastal wrote: post #55
de_keyboard wrote: post #48

Earlier quoted context omitted.

I agree. GitHub Actions should call your scripts but your scripts should not depend on GitHub Actions API. I also suggest Bazel as a consideration alongside Make. With Bazel, you get two advantages over Make: 1. It is easier to ensure that what GitHub Actions runs and builds is the same as what you have locally, since Bazel can fetch toolchains as part of the build process 2. Using a Bazel remote cache, you do not ha…

Same can be said about Nix and as a bonus you get Nix instead of Starlark

Nix & Make is the True Engineer(tm)'s Bazel.

Re: Act: Run your GitHub Actions locally

#60

Post by mikepurvis »

Arnavion wrote: post #33

Rather than replacing your Makefile with GH Actions, replace your GH Actions with a Makefile, and make your GH Actions run `make` in a script task. Do you really need that GH Action for pulling Docker images / installing $language_compiler / creating cloud resources ? A `docker` / `curl` / `sudo apt-get install` invocation in a Makefile / script needs to be written once and is the same in CI as on your dev machines.…

I’ve run into this with overly complicated Jenkins pipeline files as well. I think the root cause is just that a single entry point pipeline is boring— everyone wants a CI config that sets statuses and posts results and does things in parallel and interacts with plugins, and every one of those steps is something that is at least semi unique to the CI execution environment.

I think the method you describe is still absolutely how it should be, but this types of interactions are why there’s gravity in the other direction.

Post reply on HN