Work with GitHub Actions in Your Terminal with GitHub CLI | Hacker News Reader

Work with GitHub Actions in Your Terminal with GitHub CLI

github.blog

139 pointstodsacerdoti66 comments

Am I missing something obvious or do these kinds of systems lack a good story for testing?

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.

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 doesn't help the yaml ui/ux is awful.

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

Just let us write our entire pipelines in typescript. People are already using Actions for bitcoin mining, hosting porn, or whatever - if I can do arbitrary shell stuff you're not making my life easier by putting it behind a yaml DSL pretending to be "no code."

If it were just typescript with a reasonable library we could run and debug it locally without jumping through hoops.

/rant

yup and with proper IDE support as well

What CI/CD system other than Jenkins uses a configuration format that isn't YAML?

Team City. But Jenkins is still king.

I think one either loves it or hates it..

Buildbot

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.

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.

Pushing countless commits is fine as long as you are doing it in your own branch.

It's not very cost-effective though.

If CI cost is a problem then test everything locally before pushing.

…but the point is they’re testing CI itself, which doesn’t exist locally.

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.

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

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

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.

Codeship does this too with their `jet` command.

This project may be able to help you out: https://github.com/nektos/act/ (it provides a way to run GitHub actions locally)

Amazing that somebody developed that for Microsoft.

they probably developed it for themselves.

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.

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.

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.

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.

Countless commits with the same message "flailing" until it works. Typically takes about 30.

Maybe you will be interested in https://earthly.dev/

Sourcehut at least lets you submit build manifests to builds.sr.ht without having to push, push, push.

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

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.

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.

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.

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.

That's an even better solution.

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.

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.

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

action-tmate... woah!

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.

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.

One approach to avoid this karlicoss is to add a “workflow dispatch” section to the “on” events in the workflow:

  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

Then under the job steps, make the debug step conditional on that optional flag:

     # 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 }}

You then can just trigger the build on the required branch, setting debug_enabled to true and voila.

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

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

> 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

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

This same script is used for the server and client. So you are running this on your workstation.

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

The ability to ssh into the Travis VM and investigate the terminal state on failure is just amazing.

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.

Post-fail ssh access is one of the headline features of https://builds.sr.ht

I've used https://github.com/nektos/act in the past. It works ok as long as you don't need artifacting.

I mostly struggle with the docs to be honest.

But yeah, SSHing in is great. I miss that from Circle using GL & GH.

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.

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?

I've implemented each of these features using public apis, so... Probably?

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'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!

Reply on news.ycombinator.com