Integrate GitHub actions debug mode detection

[webknjaz]

This should be possible by inspecting the following information sources:

• RUNNER_DEBUG (environment variable): https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#default-environment-variables
• ACTIONS_RUNNER_DEBUG (var or secrets context): https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/troubleshooting-workflows/enabling-debug-logging#enabling-runner-diagnostic-logging
• ACTIONS_STEP_DEBUG (var or secrets context): https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/troubleshooting-workflows/enabling-debug-logging#enabling-step-debug-logging

There's additionally ${{ runner.debug }} to look at: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#runner-context.

Ref: https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/re-running-workflows-and-jobs#about-re-running-workflows-and-jobs

We may also want to take the rerun attempt into account.

Could provide a skip-existing-on: rerun | debug | second/third-attempt or something.

[Jomik]

Meanwhile, we can add

with:
  verbose: ${{ toJSON(runner.debug == '1') }}

[webknjaz]

@Jomik nice find! Though, what I have in mind is a more integrated approach. This input only adds --verbose to twine upload. Meanwhile, we also have a few places where we print stuff that would be good to integrate.

[webknjaz]

Observations: when restarting jobs and using that checkbox to enable debug logging, GHA internally sets ${{ secrets.ACTIONS_STEP_DEBUG == 'true' }} and ${{ secrets.ACTIONS_RUNNER_DEBUG == 'true' }}.

And when ACTIONS_STEP_DEBUG is set, runner.debug is set, too.

This means, that whether the internal GHA machinery within the runners is requested to output detailed logs can be detected with ${{ secrets.ACTIONS_RUNNER_DEBUG == 'true' || (secrets.ACTIONS_RUNNER_DEBUG != '' && vars.ACTIONS_RUNNER_DEBUG == 'true') }} and is not directly inspectable from runtime. This would work in composite actions, but if they call some other scripts, the mode would have to be passed through. If this is set, the logs downloadable from GHA job run contain a runner-diagnostic-logs/ folder, which is not present otherwise. That folder contains a .zip file, which needs to be unpacked too, and it contains two text files — Runner_*.log and Worker_*.log.

Refs https://github.com/actions/toolkit/blob/main/docs/action-debugging.md#step-debug-logs.

And detecting the step debug (for user-provided actions or run-steps) has more ways:

1. ${{ runner.debug == '1' }} in composite actions
2. ${{ secrets.ACTIONS_STEP_DEBUG == 'true' || (secrets.ACTIONS_STEP_DEBUG != '' && vars.ACTIONS_STEP_DEBUG == 'true') }} in composite actions
3. ${{ env.RUNNER_DEBUG == '1' }} in composite actions
4. [[ "${RUNNER_DEBUG}" == '1' ]] in called bash scripts, run-steps and anything external (os.getenv('RUNNER_DEBUG') == '1' in Python, for example)

Additionally, printing out ::debug:: workflow commands in steps is evaluated by the runner and shows up depending on ACTIONS_STEP_DEBUG too.

The question is whether we need to care about the runner debug requests or not.