[degraafc]

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

[karlicoss]

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.

[horse666]

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]

oh, nice trick, thanks!

[horse666]

Thought I'd get their docs updated - https://github.com/mxschmitt/action-tmate#manually-triggered...

[degraafc]

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.

[jrochkind1]

action-tmate... woah!