Consume and troubleshoot workflows practice questions

Reading a trigger means combining branch filters for each event with the default activity types of pull_request, and knowing that a merge is a push to the base branch.

The push event is filtered to main, so pushing to feature/login creates nothing. pull_request with branches: [main] filters on the base branch; with no types listed it runs for opened, synchronize and reopened, so opening the pull request and pushing another commit each start a run. Merging creates a commit on main, which is a push to main and starts the third run. A closed activity is not in the default list, so there is no separate run for closing.

1. Apply the push branch filter to each push: feature/login fails it, the merge into main passes it.
2. Recall the default pull_request activity types: opened, synchronize and reopened.
3. Match each action: open is opened, the extra commit is synchronize.
4. Count the runs: two pull_request runs plus one push run.

Exam tip: pull_request without types runs on opened, synchronize and reopened; a merge shows up as a push to the base branch.

A workflow skipped by a path, branch or commit-message filter creates no run and leaves its checks pending, whereas a job skipped by an if condition reports Success.

GitHub documents that when a workflow is skipped by path filtering, branch filtering or a commit message, the checks associated with it remain Pending, so a required check blocks the merge. Moving the decision inside the workflow fixes this: the workflow always runs, a first job works out which files changed, and the test job's if skips it for docs-only changes. A job skipped by a conditional reports Success, which satisfies the required check, and src/ changes still run the tests. paths-ignore and [skip ci] are just other ways of skipping the whole workflow, and branch protection cannot scope a required check by path.

1. Recall why the check is pending: no run exists because the trigger filter skipped the workflow.
2. Reject any option that still skips the workflow at the trigger or commit level.
3. Recall that a job skipped by its if condition reports Success to required checks.
4. Choose the option that always creates a run and skips only the job.

Exam tip: Skipped workflows leave required checks pending; skip the job with if instead.

For the pull_request event, GITHUB_SHA is the last merge commit on GITHUB_REF, which is refs/pull/<number>/merge.

GitHub tests what the pull request would produce once merged: it creates a merge commit of the head branch into the base branch on refs/pull/<number>/merge, and the run's GITHUB_SHA is that commit. actions/checkout checks out GITHUB_SHA by default, so HEAD is the merge commit and its SHA matches no commit on the head branch. GitHub does not rebase the branch, the base branch tip lacks the pull request's changes, and the default-branch commit is what pull_request_target uses.

1. Note the event: pull_request, with checkout using its defaults.
2. Recall that pull_request runs use GITHUB_REF refs/pull/<number>/merge.
3. Recall that GITHUB_SHA is the last merge commit on that ref and checkout fetches it.
4. Conclude that HEAD is a merge commit, not a head branch commit.

Exam tip: pull_request runs build refs/pull/N/merge, a merge commit, not the head branch tip.

Step debug logging is enabled by setting ACTIONS_STEP_DEBUG to true as a repository secret or variable; runner diagnostic logging uses ACTIONS_RUNNER_DEBUG.

Debug messages (core.debug or the ::debug:: workflow command) are hidden unless step debug logging is enabled. Setting ACTIONS_STEP_DEBUG to true as a secret or variable in the repository turns it on for later runs with no workflow change. ACTIONS_RUNNER_DEBUG is the near-twin that adds runner diagnostic logs to the archive instead, RUNNER_DEBUG is an indicator the runner sets, and a CLI flag cannot reveal lines that were never logged.

1. Identify the output wanted: debug messages inside step logs.
2. Match it to step debug logging, not runner diagnostic logging.
3. Set ACTIONS_STEP_DEBUG to true as a secret or variable.
4. Reject options that edit workflows or only change how logs are viewed.

Exam tip: ACTIONS_STEP_DEBUG shows debug messages in step logs; ACTIONS_RUNNER_DEBUG adds runner diagnostics.

Debug logging can be turned on for a single re-run, in the UI or with gh run rerun --debug, without changing secrets or variables.

When re-running a workflow or its failed jobs, anyone who can run the workflow can enable runner diagnostic logging and step debug logging for that re-run only. That retries the same run with full debug output, needs no commit, and does not affect other runs. Repository secrets or variables would enable debug logging for every subsequent run, adding set -x needs a commit, and the archive of the original run has no runner diagnostics because they were off.

1. List the constraints: same failed run, no commit, no repository-wide setting.
2. Recall that a re-run can enable debug logging for itself.
3. Choose the re-run with debug logging selected.
4. Reject options that need a commit or affect every run.

Exam tip: Use re-run with debug logging for a one-off investigation; use the secrets or variables for ongoing debugging.

On Linux and macOS, a run step with no shell uses bash -e {0}; shell: bash adds -o pipefail, so a failure anywhere in a pipeline fails the step.

Without pipefail, a pipeline's exit status is the status of its last command. tee succeeds, so the step exits 0 even though npm test failed. When no shell is specified the runner uses bash -e {0}; when shell: bash is specified it uses bash --noprofile --norc -eo pipefail {0}, so the failed npm test fails the step while tee still writes the file. sh has no pipefail, continue-on-error is already false, and if only controls whether the step runs.

1. Spot the pipe: the step's status comes from tee.
2. Recall the default shell command: bash -e, without pipefail.
3. Recall that shell: bash adds -o pipefail.
4. Reject settings that do not change the exit code.

Exam tip: An unspecified shell is bash -e; shell: bash adds pipefail, so piped failures fail the step.