Task 2.1: Interpret workflow behavior and results

• AThe required check is reported as skipped, which counts as passing

  Incorrect

  The check from a skipped workflow stays Pending, which blocks a merge that requires it.

• BThe CI workflow doesn't run for this commit

  Correct

  Skip instructions stop workflows triggered by push and pull_request for that commit.

• CNeither the CI workflow nor the labeling workflow on pull_request_target runs

  Incorrect

  Skip instructions apply only to push and pull_request, not to pull_request_target.

• DThe labeling workflow on pull_request_target still runs

  Correct

  pull_request_target isn't affected by skip instructions in commit messages.

• ENo later commit can update the pull request until the skip is removed

  Incorrect

  A new commit without the skip instruction starts the workflow again.

Workflows triggered by push or pull_request aren't started when the commit message, or the head commit of a pull request, contains [skip ci] or a similar instruction. Skip instructions don't apply to other events such as pull_request_target. Checks from a skipped workflow stay Pending, so a pull request that requires them is blocked until a new commit without the instruction runs the workflow.

• ARe-run the last CI run from the Actions tab

  Incorrect

  A re-run repeats an earlier run's commit and doesn't create a run for the new commits.

• BAdd the reopened activity type and reopen the pull request

  Incorrect

  reopened is a default type already, and the conflict still blocks the run.

• CResolve the merge conflict with the base branch

  Correct

  pull_request workflows don't run while the pull request has a merge conflict.

• DSwitch the CI workflow to pull_request_target on the base branch

  Incorrect

  That event runs the base branch's code, not the pull request's, so it wouldn't test the change.

Workflows don't run on pull_request activity if the pull request has a merge conflict; the conflict must be resolved first. pull_request_target runs even with a conflict, but it doesn't test the pull request's changes.

• ARe-run the failed jobs again with debug logging enabled

  Incorrect

  Failed-job re-runs keep using the reusable workflow commit of the first attempt.

• BRe-run the single failed job instead of all failed jobs

  Incorrect

  A specific job re-run also uses the first attempt's reusable workflow commit.

• CRe-run all jobs in the run

  Correct

  Re-running all jobs resolves the reusable workflow from the referenced tag, which now points to the fix.

• DDelete the run so that its next attempt starts clean

  Incorrect

  A deleted run can't be re-run at all.

When a reusable workflow is referenced by tag or branch rather than SHA, re-running all jobs uses the reusable workflow from the specified reference, while re-running failed jobs or a specific job uses the commit SHA from the first attempt.

• ANo runner has a matching label

  Correct

  The label is misspelled, so no GitHub-hosted or self-hosted runner matches the job.

• BThe job waits for an environment's required reviewers

  Incorrect

  The job references no environment, and a review wait shows as waiting for review.

• CThe concurrency group already holds a pending run

  Incorrect

  The job has no concurrency group, and other jobs start normally.

• DEvery runner is busy because the repository hit its concurrent job limit

  Incorrect

  Other jobs in the repository start within seconds, so the limit isn't reached.

A job waits in the queue until a runner whose labels match runs-on picks it up. A misspelled label matches no runner. GitHub recommends unique labels for self-hosted and larger runners, and the GitHub-hosted labels are listed in the runner reference.

• AGitHub adds them to every job

  Correct

  GitHub adds these two steps to set up and complete each job's execution.

• Bactions/checkout adds them when it runs

  Incorrect

  They appear even in jobs that don't use checkout.

• CAn organization-wide required workflow

  Incorrect

  A required workflow is a separate run, not extra steps in each job.

• DThe runner image's startup scripts

  Incorrect

  They appear on self-hosted runners too.

In addition to the steps configured in the workflow file, GitHub adds two steps to each job, Set up job and Complete job, which set up and complete the job's execution.

• AThe repository's Insights tab

  Incorrect

  Insights shows repository activity, not one run's jobs.

• BThe workflow's status badge

  Incorrect

  A badge shows only whether the workflow passes or fails.

• CThe visualization graph on the run's summary page

  Correct

  The graph shows each job, its dependencies and its status.

• DThe repository's Actions settings page for the workflow

  Incorrect

  Settings configure Actions; they don't show a run's jobs.

Each workflow run has a visualization graph that shows the jobs, their dependencies and their progress, which helps find the job that others are waiting on.

• ATo sign in with a GitHub account

  Correct

  Viewing workflow run information such as logs needs a signed-in GitHub account, even for public repositories.

• BRead access to the repository, granted by a maintainer

  Incorrect

  The repository is public, so it's already accessible to everyone; what's missing is a signed-in account.

• CTo wait until the run's logs have finished uploading

  Incorrect

  The run has already failed and completed, so its logs are there; what's missing is a signed-in account.

• DThe log archive, which can be downloaded without signing in

  Incorrect

  The log archive is part of the workflow run information that needs a signed-in account.

You must be logged in to a GitHub account to view workflow run information, including for public repositories, so a signed-out visitor can't read or download a job's logs until she signs in. Public repositories are accessible to everyone, so no extra repository access is needed once she is signed in.

• AThree re-runs, after which a new run is needed

  Incorrect

  The limit is much higher than three.

• B50 re-runs, counting full and partial re-runs

  Correct

  A run can be re-run up to 50 times, whether all jobs or some are re-run.

• CNo limit while the run is less than 30 days old

  Incorrect

  The 30-day window and the 50 re-run limit both apply.

• DTen re-runs per job, counted separately for each job

  Incorrect

  The limit counts re-runs of the workflow run, not each job.

A workflow run can be re-run a maximum of 50 times, including both full re-runs and re-runs of a subset of jobs, and only within 30 days of the initial run.