[HN Gopher] Work with GitHub Actions in Your Terminal with GitHu...
___________________________________________________________________
Work with GitHub Actions in Your Terminal with GitHub CLI
Author : todsacerdoti
Score : 88 points
Date : 2021-04-15 16:02 UTC (6 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| rurban wrote:
| 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
| hctaw wrote:
| 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
| jrochkind1 wrote:
| Do these CLI functions use public HTTP API that other tools could
| use for GH Actions?
| wungsten wrote:
| Yes. You can authenticate "other tools" using a personal access
| token or GitHub App.
| https://docs.github.com/en/rest/reference/actions
| de-moray wrote:
| I've implemented each of these features using public apis,
| so... Probably?
| petethepig wrote:
| 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.
| Waterluvian wrote:
| The ability to ssh into the Travis VM and investigate the
| terminal state on failure is just amazing.
| trinovantes wrote:
| 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.
| milliams wrote:
| 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.
| derefr wrote:
| 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.
| petethepig wrote:
| That's an even better solution.
| rvieira wrote:
| 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.
| degraafc wrote:
| 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
| jrochkind1 wrote:
| action-tmate... woah!
| karlicoss wrote:
| 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.
| degraafc wrote:
| 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.
| horse666 wrote:
| 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.
| karlicoss wrote:
| oh, nice trick, thanks!
| seniorThrowaway wrote:
| 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.
| crazysim wrote:
| 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).
| kevincox wrote:
| > 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
| derefr wrote:
| > 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.
| kevincox wrote:
| This same script is used for the server and client. So
| you are running this on your workstation.
| sbaildon wrote:
| Post-fail ssh access is one of the headline features of
| https://builds.sr.ht
| [deleted]
| ollien wrote:
| I've used https://github.com/nektos/act in the past. It works
| ok as long as you don't need artifacting.
| kody wrote:
| 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).
| [deleted]
| diveanon wrote:
| 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.
| Waterluvian wrote:
| 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.
| vnglst wrote:
| 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.
| cbb330 wrote:
| 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-...
| mfontani wrote:
| 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.
| mdaniel wrote:
| 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/5b36dc6502d0680
| 4c083...
|
| 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
| jka wrote:
| This project may be able to help you out:
| https://github.com/nektos/act/ (it provides a way to run GitHub
| actions locally)
| thamer wrote:
| 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.
| pydry wrote:
| Amazing that somebody developed that for Microsoft.
| madeofpalk wrote:
| they probably developed it for themselves.
| chatmasta wrote:
| 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.
| hctaw wrote:
| 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.
| bellttyler wrote:
| I do the same. Dozens of commits to get GH Actions working
| correctly.
| Waterluvian wrote:
| I feel far better hearing a few people say they do it the
| same.
|
| It felt so wrong and amateur and kind of embarrassing.
| hctaw wrote:
| 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
| paxys wrote:
| Pushing countless commits is fine as long as you are doing it
| in your own branch.
| jensvdh wrote:
| It's not very cost-effective though.
| paxys wrote:
| If CI cost is a problem then test everything locally before
| pushing.
| amarshall wrote:
| ...but the point is they're testing CI itself, which
| doesn't exist locally.
___________________________________________________________________
(page generated 2021-04-15 23:00 UTC)