A maintainer is investigating why a custom action behaves differently on the runner than expected, but the standard run log shows only the action's own output and no internal step diagnostics. They want GitHub Actions to emit the additional step debug messages for the re-run without editing the action's source. What should they do to surface that extra diagnostic logging?
Repository settings -> Secrets and variables -> Actions
# add a value, then re-run the failed job- ASet a repository configuration variable named ACTIONS_RUNNER_DEBUG to the string verbose, because that level controls how much step diagnostic output the runner prints.
- BAdd a step that runs echo with the ::debug:: workflow command, because writing that command in the calling workflow retroactively reveals the action's own internal debug lines.
- CSet a secret or variable named ACTIONS_STEP_DEBUG to true, then re-run the job, because that value tells the runner to emit the additional step debug log lines. Correct
- DRe-run the job with the Enable debug logging checkbox, which permanently raises the verbosity for every future run in the repository until it is cleared.
Why A is wrong: Tempting because ACTIONS_RUNNER_DEBUG is a genuine debug toggle, but it enables runner diagnostics and is set to true, not to a verbose level, so it does not surface the step debug messages this question asks for.
Why B is wrong: Tempting because ::debug:: is the real debug workflow command, but it only prints a message the author writes and is shown when debug logging is on. It cannot reveal another action's internal diagnostics.
Why C is correct: Setting ACTIONS_STEP_DEBUG to true makes the runner emit the extra step-level debug output on the next run, surfacing the internal diagnostics without changing the action's source code.
Why D is wrong: Tempting because re-running with debug logging is a valid path, but that option applies only to the single re-run and is not a permanent repository-wide verbosity setting as described.