actions/setup-debugger: Interactively inspect and manipulate steps of a workflow job

[tsibley]

Interception is still slightly flaky at times for as-of-yet unclear reasons, but overall it works! This is a quick initial implementation to see if such a debugger is actually useful in practice. There are alternative ways to accomplish the ~same functionality, which I'll describe elsewhere later (and one of which I've prototyped). One of those may ultimately be a better choice if this debugger does prove its worth.

Testing

• Tested extensively during development
• Checks pass

[tsibley]

Once CI passes, I'll likely merge this. It's a dev-only action, unused by anything non-transient at the moment.

[victorlin]

This sounds like it would've been useful as an alternative to debugging nextstrain/cli#249 using a personal test workflow. Didn't try yet, but I assume the new alternative would be to:

1. Add this step at the beginning of cli/.github/actions/setup-integration-tests/action.yaml.
   • Note that since the steps to be debugged are within an action, it would require propagating the tailscale-auth-key input up to the workflow level (cli/.github/workflows/ci.yaml).
2. Let the debugger run past setup-miniconda and other steps, up until name: Check python version.
3. Given the state at this point in the workflow, manually run commands such as python --version to inspect output.

I'll note that a nice thing about running test workflows over this approach is the easy parallelism that comes with it. In this example, it was easy to run a test workflow and check the outputs for multiple Python versions. With Tailscale, I assume this would require creating 1 Tailscale auth key per job, which sounds tedious.

[tsibley]

This sounds like it would've been useful as an alternative to debugging nextstrain/cli#249 using a personal test workflow.

Not sure if it would have been useful there. Maybe!

Overall, I'm not sure how useful this debugger will turn out to be, but I wanted to try it and see! :-) The idea had been bouncing around my head for a long time.

Note that since the steps to be debugged are within an action, it would require propagating the tailscale-auth-key input up to the workflow level (cli/.github/workflows/ci.yaml).

It wouldn't have to be a workflow-level input if the auth key was stored as a secret, but yes, at a minimum it requires making the auth key an input to the containing action, setup-integration-tests, since actions can't read the secrets context directly.

Ideally, we'd have longish-lived auth keys for this stored as secrets, connected to a team Tailscale account (as discussed elsewhere).

Given the state at this point in the workflow, manually run commands such as python --version to inspect output.

A limitation of the current impl. is not being able to run a subprocess of the attached/debugged process. This would be possible with one of the alternative/additional approaches.

What you could do is inspect the environment of the process and edit the shell script to try additional things out. (You could also probably re-attach the step's stdin to your current TTY and invoke an interactive subshell, but I haven't tried that.)

With Tailscale, I assume this would require creating 1 Tailscale auth key per job, which sounds tedious.

Nope, you'd make a "reusable" (but still ephemeral) auth key in Tailscale and pass that to the whole workflow. (And ideally there's a team-shared auth key available as a secret so no input is required.)