Consume and troubleshoot workflows

Your organization maintains a private repository named `.github` that contains a workflow template (a `.yml` file plus its `.properties.json`) in the `workflow-templates/` directory. A developer on a private application repository within the same organization wants to use this template to scaffold a new workflow. Where and how does the developer access this non-public organization workflow template?

A workflow defines a build job with the following strategy: ```yaml jobs: build: strategy: fail-fast: false matrix: os: [ubuntu-latest, windows-latest] node: [18, 20] runs-on: ${{ matrix.os }} steps: - run: npm test ``` In the Actions UI run summary, one job shows a red X while the other three are green. The failing job is named `build (windows-latest, 20)`. Your teammate insists the failure is caused by the Node version because "20 is the last value shown." How should you interpret this job name to identify the failing variant?

A workflow run for your CI pipeline shows a red X on the 'build' job. When you open the run summary page in the GitHub UI, an annotation reads 'Process completed with exit code 1' but does not indicate which command failed. Your team needs to pinpoint the exact command and error message that caused the failure. Which action gives you the most direct path to that information?

A scheduled workflow named 'nightly-report.yml' has been failing every night and flooding your team's notifications. The workflow will be needed again once an upstream dependency is fixed next quarter. Your team lead asks you to stop the runs immediately while keeping the file in the repository and preserving all past run history for auditing. Which action in the Actions UI best satisfies these requirements?

Your platform team wants a single, centrally maintained CI definition. When they publish a new version, all consuming repositories should immediately pick up the change on their next run without any of those repos editing files. The consuming repos invoke it by referencing its path and a ref. Which mechanism satisfies these requirements?

A teammate asks you to retrieve the build artifact named 'app-bundle' from a workflow run that completed 95 days ago. Your organization uses the default artifact retention setting. When you open the run in the GitHub UI, the Summary page no longer lists any artifacts under the 'Artifacts' section, and the API call to list artifacts for that run returns an empty array. The workflow logs, however, clearly show the 'Upload artifact' step succeeded at the time. What is the most accurate explanation and next step?

A teammate reports that a workflow run from three days ago produced a build artifact named 'release-bundle', but the run's UI page no longer shows a download link under the Artifacts section. You need to retrieve that artifact programmatically for an audit. Assuming the artifact has not exceeded its retention period, which approach correctly downloads it via the GitHub REST API?

A teammate reports that a nightly workflow named 'build-and-package' produced a broken installer. You know the workflow completed three hours ago but you only have the workflow file name, not the specific run. Using the GitHub REST API, what is the correct sequence to retrieve and download the artifact produced by that latest completed run?

A platform engineer is building an internal dashboard that must automatically archive the complete log bundle (a ZIP of all job logs) for every completed workflow run in a repository. They want to fetch these logs programmatically rather than clicking through the GitHub UI. Which REST API request retrieves the downloadable log archive for a specific workflow run?

A teammate asks you to retrieve the 'coverage-report' artifact from a workflow run that completed 95 days ago. You open the run's summary page in the GitHub UI, but the Artifacts section is empty even though the run's logs clearly show an 'Upload artifact' step that succeeded. The repository uses the default artifact retention settings. What is the most likely reason the artifact is unavailable, and what should you do?

Your platform team maintains a reusable workflow in the repo `acme/ci-shared` at `.github/workflows/deploy.yml`. A consuming repository invokes it like this: ```yaml jobs: ship: uses: acme/ci-shared/.github/workflows/deploy.yml@v2 secrets: inherit ``` The platform team just pushed a bug fix to the `main` branch of `acme/ci-shared` but has NOT moved or recreated the `v2` tag. A developer reports the consuming repo's runs still execute the old, buggy logic. What is the correct explanation?

A developer opens the Actions tab and sees a run of the 'deploy' workflow. The run's summary header shows the run was started by user 'octo-admin' and lists 'Triggered via manual event'. However, the deploy workflow YAML contains this triggers block: ```yaml on: push: branches: [main] workflow_dispatch: schedule: - cron: '0 3 * * *' ``` The developer wants to confirm what actually caused THIS specific run to start. Based on the run header information alone, which trigger initiated the run?

A developer's workflow uses a composite action named 'setup-tooling' that bundles four internal steps (checkout helper, install dependencies, configure cache, and verify install). A run fails and the job log shows the composite action step marked with a red X, but the top-level step summary only lists the composite action's name, not which internal step broke. Where in the UI should the developer look to identify exactly which of the four inner steps failed?

A teammate reports that a workflow named 'deploy.yml' did not run when they pushed a commit directly to the 'develop' branch, even though it ran fine on other branches earlier. The workflow's trigger configuration is: ```yaml on: push: branches: - 'main' - 'release/**' tags: - 'v*' ``` Based on this configuration, why did the push to 'develop' not start the workflow?

A release engineer wants to build an internal dashboard that lists all artifacts produced by a specific workflow run, showing each artifact's name, size, and whether it has expired. They plan to call the GitHub REST API from a backend service. Which single API request returns exactly this information for one workflow run?

A release engineer wants to build a dashboard that shows only the most recent failed runs of the workflow defined in .github/workflows/deploy.yml for the main branch. They plan to call the GitHub REST API to retrieve this data programmatically. Which approach correctly returns only those failed runs?

A teammate shares this workflow snippet and asks how many jobs the matrix will produce and whether the shared config applies to every variant: ```yaml jobs: test: strategy: matrix: os: [ubuntu-latest, windows-latest] node: [18, 20] runs-on: ${{ matrix.os }} steps: &common-steps - uses: actions/checkout@v4 - run: node --version ``` You notice `&common-steps` is defined here but no `*common-steps` alias is referenced anywhere else in the file. What is the actual behavior of this workflow?

A workflow contains the following job strategy: ```yaml jobs: test: strategy: matrix: os: [ubuntu-latest, windows-latest] node: [16, 18, 20] exclude: - os: windows-latest node: 16 include: - os: macos-latest node: 20 runs-on: ${{ matrix.os }} steps: - run: node --version ``` When this workflow runs, how many jobs will appear in the run's job list?

A developer defines the following matrix strategy in a workflow job named `test`: ```yaml jobs: test: strategy: matrix: os: [ubuntu-latest, windows-latest] node: [16, 18, 20] include: - os: ubuntu-latest node: 20 experimental: true runs-on: ${{ matrix.os }} ``` In the Actions UI checks list, one variant appears as `test (ubuntu-latest, 20, true)` and shows a red X, while `test (ubuntu-latest, 20)` is not listed separately. What does this tell you about the failed variant?

A nightly workflow ran three days ago and two of its five jobs failed due to a transient network issue with an external package registry. The default branch has received several new commits since then. A developer opens the completed run in the GitHub UI and clicks "Re-run failed jobs". Which statement correctly describes what happens?