Work with GitHub Actions in Your Terminal with GitHub CLI(github.blog)
github.blog
Work with GitHub Actions in Your Terminal with GitHub CLI
https://github.blog/2021-04-15-work-with-github-actions-in-your-terminal-with-github-cli/
72 comments
This project may be able to help you out: https://github.com/nektos/act/ (it provides a way to run GitHub actions locally)
I've tried to get `act` to work several times over the past few months, and never managed to get even a basic workflow to run locally. It kept giving cryptic errors that I had to dig into their code to figure out (e.g. requiring a GitHub Personal Access Token despite not mentioning it in the docs). It gave me the impression that it was far from functional, for now.
I eventually gave up and have been running Actions on GitHub from a branch, merging into the main one once it works.
I eventually gave up and have been running Actions on GitHub from a branch, merging into the main one once it works.
How come Github doesn't have this? Just lemme run it locally. I've wasted so much time debugging my workflows... It's such a obvious miss.
Amazing that somebody developed that for Microsoft.
they probably developed it for themselves.
I use this action* to effectively put a 'breakpoint' in a job that lets you SSH in and inspect the env vars, files, refine your shell script code, etc. Cuts way down on the number of CI run/tweak/repeat cycles.
* https://github.com/marketplace/actions/debugging-with-tmate
* https://github.com/marketplace/actions/debugging-with-tmate
I do the same. Dozens of commits to get GH Actions working correctly.
I feel far better hearing a few people say they do it the same.
It felt so wrong and amateur and kind of embarrassing.
It felt so wrong and amateur and kind of embarrassing.
It doesn't help the yaml ui/ux is awful.
If it were just typescript with a reasonable library we could run and debug it locally without jumping through hoops.
/rant
- if ${{ github.event_name == 'why do you think this is acceptable?" }}
run:|
echo "I need programmatic CI no matter how much you think I don't"
If it were just typescript with a reasonable library we could run and debug it locally without jumping through hoops.
/rant
I don't get it how Python exists. Even with the best IDE support writing YAML is a misery.
I write Python for years (including messing code) and never feel the pain I found when I edit an even a slightly complicated YAML file.
The issue is not really the significant indentation of YAML, it is more of the ambiguity of the syntax plus the fact that YAML is a serialization format so it doesn't have many ways to reduce repetition. Now those issues coupled with the significant indentation makes YAML a mess, but those issues doesn't exist in Python.
The issue is not really the significant indentation of YAML, it is more of the ambiguity of the syntax plus the fact that YAML is a serialization format so it doesn't have many ways to reduce repetition. Now those issues coupled with the significant indentation makes YAML a mess, but those issues doesn't exist in Python.
yup and with proper IDE support as well
I've been making a custom build image in large part because of this. Local testing with Docker isn't the most fun, I have to manually manage the environment variables I pass on the command line, but it's way better than commit then wait for Docker to schedule.
Once it's working locally I push up and it's usually only a commit or two away from working.
Once it's working locally I push up and it's usually only a commit or two away from working.
Countless commits with the same message "flailing" until it works. Typically takes about 30.
I suppose we all just brute force it.
For my private projects, I just make it rain with minor incremental improvements, and once it is green, I rebase and squash.
For shared/OS projects, I'd rather fork it and then work on my fork, so I don't trigger emails or other webhooks.
For my private projects, I just make it rain with minor incremental improvements, and once it is green, I rebase and squash.
For shared/OS projects, I'd rather fork it and then work on my fork, so I don't trigger emails or other webhooks.
Sourcehut at least lets you submit build manifests to builds.sr.ht without having to push, push, push.
if I remember correctly CircleCI is the only CI-provider that would let you run their pipelines/actions locally in a Docker container. That worked really well for me, quick feedback loop without creating commits.
Drone CI, too - you can "drone exec" a pipeline and it'll work the same way as on the CI server. It's a great feature to have.
I've resorted to running my own local copy of GL (and, of course, its runner) for troubleshooting build complexity, since their runner pool has been so indescribably bad of late: https://status.gitlab.com/pages/history/5b36dc6502d06804c083...
I agree with the other comments that CircleCI is my high-bar for "how can a sane person run the build locally?" because I also agree with the other comments that "act" is handy, but only for the most trivial of hello-world builds, and `gitlab-runner exec` is a cruel joke
I agree with the other comments that CircleCI is my high-bar for "how can a sane person run the build locally?" because I also agree with the other comments that "act" is handy, but only for the most trivial of hello-world builds, and `gitlab-runner exec` is a cruel joke
Gitlab also offers this feature [0] [1]
[0] - https://docs.gitlab.com/ee/ci/quick_start/#ensure-you-have-r...
[1] - https://medium.com/@umutuluer/how-to-test-gitlab-ci-locally-...
[0] - https://docs.gitlab.com/ee/ci/quick_start/#ensure-you-have-r...
[1] - https://medium.com/@umutuluer/how-to-test-gitlab-ci-locally-...
Codeship does this too with their `jet` command.
Haven't found a better way than `./ci.sh` and do as much work as possible to keep github actions/travis/jenkins/whatever from requiring something different than running locally.
It's sisyphean.
It's sisyphean.
In our stack we use a custom CI runner and that's the image we give to gitlab-ci, so it's easy to just test locally. Not sure what the story is with GHA, but generally I try to make sure everything fits into one script so I can just test that. A more fun/hacky option is opening a reverse shell on the CI box. I was even able to get it working through ngrok to my local machine.
Maybe you will be interested in https://earthly.dev/
[deleted]
Cannot this be used for running it with a local change? If no,t what's the point? (Not complaining to you but seriously.)
The biggest problem with Actions that I see a lot of people struggle with is that you can’t easily debug things when they aren’t going well.
I think they need to add some way for users to be able to ssh into the worker. Maybe each time an action step fails you have 5 mins to ssh into the container and inspect what’s going on.
I think they need to add some way for users to be able to ssh into the worker. Maybe each time an action step fails you have 5 mins to ssh into the container and inspect what’s going on.
I use tmate[1] to get a shell on the worker when I need to debug things interactively. Also act[2] lets you run a decent approximation of your actions locally. Still agree that it should be easier and not require third-party tools/actions, though.
[1]: https://github.com/mxschmitt/action-tmate [2]: https://github.com/nektos/act
[1]: https://github.com/mxschmitt/action-tmate [2]: https://github.com/nektos/act
Yeah, the only downside of tmate is that you need to add/uncomment the line with it, push, then remove the commit again.
It's much nicer in circleci, for example where you can simply rerun wish SSH in a button click. Even better would be if the VM was around for a bit after failing, so I could connect and inspect the state without rerunning at all.
One approach to avoid this karlicoss is to add a “workflow dispatch” section to the “on” events in the workflow:
Edit: but agree the CircleCI interface is nicer where you can just run a debug build with ssh access directly.
workflow_dispatch:
inputs:
debug_enabled:
description: 'Run the build with tmate debugging enabled (https://github.com/marketplace/actions/debugging-with-tmate)'
required: false
default: false
# Enable tmate debugging of manually-triggered workflows if the input option was provided
- name: Setup tmate session
uses: mxschmitt/action-tmate@v3
if: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.debug_enabled }}
Edit: but agree the CircleCI interface is nicer where you can just run a debug build with ssh access directly.
oh, nice trick, thanks!
Thought I'd get their docs updated - https://github.com/mxschmitt/action-tmate#manually-triggered...
Yep, definitely agree. I feel like there are a lot of areas that GitHub Actions needs improvements to catch up to other CI providers, really basic-seeming stuff like "allow failure" support and so on.
action-tmate... woah!
I really like that with GitLab you can run the CI script in a local container to debug things and then only commit and push once it's working.
GitHub doesn't have exactly that, but it does have self-hosted workflow runners (which GitLab also has, as it happens.)
If you run a local self-hosted runner, point your workflow at it, and trigger it (push/etc), then the job bounces from GitHub's backend over to your local runner, where you can then poke / prod / trace its execution.
It's not quite as "safe" — you don't get to test the workflow in advance of deploying it, but rather have to test it by deploying it. But it's still pretty useful for debugging. You can e.g. set environment variables on the runner itself, that then propagate into the job, to see how they affect the job. Or change stuff in the runner's user's home directory until the job works, to figure out what the job needs there, rather than deploying over and over with different "tweak this file or that" steps.
If you run a local self-hosted runner, point your workflow at it, and trigger it (push/etc), then the job bounces from GitHub's backend over to your local runner, where you can then poke / prod / trace its execution.
It's not quite as "safe" — you don't get to test the workflow in advance of deploying it, but rather have to test it by deploying it. But it's still pretty useful for debugging. You can e.g. set environment variables on the runner itself, that then propagate into the job, to see how they affect the job. Or change stuff in the runner's user's home directory until the job works, to figure out what the job needs there, rather than deploying over and over with different "tweak this file or that" steps.
That's an even better solution.
Post-fail ssh access is one of the headline features of https://builds.sr.ht
CircleCI lets you rerun a pipeline with ssh enabled so you can debug. It's helpful unless your failed step is at the end of a complex 20 minute deployment. I'll usually run my docker image locally, copy over the source, and run the pipeline by hand to debug, but then I have to set up all the environment variables that I get from CircleCI/Bitbucket Pipelines, and even then there's no guarantee that my local tests are identical to what I'm seeing in the pipeline (just today I hit a memory limit in Bitbucket pipelines that I couldn't recreate locally).
https://tunshell.com/ works great for *nix runners.
I made https://github.com/nelsonjchen/reverse-rdp-windows-github-ac... for the Windows runners.
Just add continue on error to the failing step and use temporarily use these kinds of tools in the next step(s).
I made https://github.com/nelsonjchen/reverse-rdp-windows-github-ac... for the Windows runners.
Just add continue on error to the failing step and use temporarily use these kinds of tools in the next step(s).
> https://tunshell.com/ works great for nix runners.
Oh and their interface is a `curl | sh` that execs whatever happens to be lying around in `/tmp/tunshell/client`. I guess* that is probably fine on a single-user system but I prefer not to run binaries that just about every process on my system can write to.
https://lets.tunshell.com/init.sh
Edit: I filed a bug https://github.com/TimeToogo/tunshell/issues/19
Oh and their interface is a `curl | sh` that execs whatever happens to be lying around in `/tmp/tunshell/client`. I guess* that is probably fine on a single-user system but I prefer not to run binaries that just about every process on my system can write to.
https://lets.tunshell.com/init.sh
Edit: I filed a bug https://github.com/TimeToogo/tunshell/issues/19
> I guess that is probably fine on a single-user system
Most of these services run your workload inside a container, so it's not even a single-user system; it's an ephemeral system. It's like anything's going to be there other than the base image + what you put there.
Most of these services run your workload inside a container, so it's not even a single-user system; it's an ephemeral system. It's like anything's going to be there other than the base image + what you put there.
This same script is used for the server and client. So you are running this on your workstation.
I'm not that familiar with GH actions, but Sourcehut has a couple of pretty nice solutions for troubleshooting: (as you mentioned) time-limited SSH into the build server and a page to edit the manifest online and re-run without having to push anything.
[deleted]
You could create a self-hosted runner to test things out on. I'm not sure how hard it is to match Github's VM configuration but I don't think they veer far from the stock ubuntu config for instance.
I've used https://github.com/nektos/act in the past. It works ok as long as you don't need artifacting.
Yea setting up Actions is a pretty awful experience. I had to constantly git add, commit --amend, force push and retrigger the run and look at print statements.
[deleted]
I mostly struggle with the docs to be honest.
But yeah, SSHing in is great. I miss that from Circle using GL & GH.
But yeah, SSHing in is great. I miss that from Circle using GL & GH.
The ability to ssh into the Travis VM and investigate the terminal state on failure is just amazing.
I've been playing with the idea of maintaining a repository of common dockerfiles, ci/cd pipelines, and kubernetes manifests with tooling for answering basic question about your app and then generating the skaffolding automatically. It would be kind of like backstage.io in this regard, but aimed at smaller companies that don't have dedicated platform teams. If anyone would use this, I would love to talk.
Still no way to test action locally.
This is especially troublesome considering that some actions only take effect once you have merged them into master.
So in order to develop an action that is using the on "delete" hook you need to disable CI on master, push your workflow to master, renable CI on master, switch to your dev branch and push a bunch of commits while iterating on your workflow.
https://docs.github.com/en/actions/reference/events-that-tri...
Github what the fuck.
Don't even get me started on the "master" -> "default" name change... "master" in the git context isn't even being used in the "master / slave" sense.
Spend less time virtue signaling and improve your horrible CI and maybe I will consider bringing my projects back.
For those of you who are going to recommend I try the "act" library, I have, and after hours of debugging esoteric errors I just gave up.
This is especially troublesome considering that some actions only take effect once you have merged them into master.
So in order to develop an action that is using the on "delete" hook you need to disable CI on master, push your workflow to master, renable CI on master, switch to your dev branch and push a bunch of commits while iterating on your workflow.
https://docs.github.com/en/actions/reference/events-that-tri...
Github what the fuck.
Don't even get me started on the "master" -> "default" name change... "master" in the git context isn't even being used in the "master / slave" sense.
Spend less time virtue signaling and improve your horrible CI and maybe I will consider bringing my projects back.
For those of you who are going to recommend I try the "act" library, I have, and after hours of debugging esoteric errors I just gave up.
I was using the beta gh actions support for a few months, and it was more stable than most comparable post-v1.0 tools. Cool blog post
Can I separate stdout/stderr logs and get it in order or is that broken on the gh CLI like on the web interface too
Do these CLI functions use public HTTP API that other tools could use for GH Actions?
Yes. You can authenticate "other tools" using a personal access token or GitHub App.
https://docs.github.com/en/rest/reference/actions
Yes, when I requested notifications support in `gh` the response was basically 'yep we want to, but it's not stable API yet'.
I've implemented each of these features using public apis, so... Probably?
I'm honestly amazed at the popularity of GitHub Actions.
This is probably the first time a proprietary Microsoft product *for developers* has had such huge popularity, even with many open source developers!
This is probably the first time a proprietary Microsoft product *for developers* has had such huge popularity, even with many open source developers!
With Travis and now GH Actions I find the fastest way to develop is to just push countless commits and incrementally develop my work flow in a live-ish way while asking peers to ignore the email spam on failures.