Bearlow's Exam Prep

bearlow./GH-200/Summaries

Author and maintain workflows · 40-45%

Consume workflows · 10-15%

Author and maintain actions · 15-20%

Manage GitHub Actions for the enterprise · 25-30%

14 summaries

summary

Access workflow artifacts and logs

Overview

Workflow artifacts are files or collections of files produced during a workflow run. They allow data to persist after a job completes and can be shared between jobs in the same workflow or reviewed after the run ends. Common artifacts include log files, test results, screenshots, binary files, and code coverage reports. GitHub provides two official actions for working with artifacts: `actions/upload-artifact` for storing files and `actions/download-artifact` for retrieving them. To upload an artifact, a workflow step uses `actions/upload-artifact` with a `name` and `path` input. If no name is provided, the default name `artifact` is used. A custom retention period can be set using the `retention-days` input, though this value cannot exceed the limit set by the repository, organization, or enterprise. To share data between jobs, a downstream job uses `actions/download-artifact` with the same artifact name and must declare a `needs` dependency on the uploading job to ensure correct execution order. Artifacts from a different workflow run or repository require a token and run identifier to download. Deleting a workflow run also deletes all its associated artifacts from storage. Workflow run logs are accessible from the Actions tab in the GitHub web interface. Read access to the repository is required to view or download logs; write access is required to delete them. Logs can be searched (only expanded steps are included in search results), downloaded as a zip archive via the gear icon in the log viewer, or viewed and filtered using GitHub CLI with commands such as `gh run view RUN_ID --log` and `gh run view --job JOB_ID --log-failed`. When a partially re-run workflow's log archive is downloaded, only the re-run jobs are included; to get a complete set, log archives from previous run attempts must also be downloaded. Logs can be deleted through the GitHub web interface or programmatically using the REST API. Within the parent section on authoring and maintaining workflows, the ability to access artifacts and logs is central to the full workflow lifecycle. Practitioners must interpret run outcomes, diagnose failures using build logs, and retrieve build outputs such as compiled binaries or test reports. Understanding how to configure artifact upload and download steps, manage retention, and retrieve logs programmatically is essential for maintaining reliable CI/CD pipelines on GitHub Actions.

Key Points

The `actions/upload-artifact` and `actions/download-artifact` actions are used to store and retrieve workflow artifacts, with `artifact` as the default name when none is specified.

Artifacts can be shared between jobs in the same workflow by using `needs` to sequence jobs and referencing the same artifact name in the download step.

A custom retention period for an artifact is set with the `retention-days` input on `upload-artifact`, and the value cannot exceed the limit configured at the repository, organization, or enterprise level.

Downloading artifacts from a different workflow run or repository requires supplying a token and run identifier to the `download-artifact` action.

Read access to the repository is required to view, search, or download workflow run logs; write access is required to delete logs.

When downloading the log archive for a partially re-run workflow, only the re-run jobs are included, so logs from previous run attempts must be downloaded separately for a complete set.

source →

Examples

Upload a build artifact with a custom retention period

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build project
        run: npm ci && npm run build
      - name: Upload build output
        uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: dist/
          retention-days: 5

This snippet shows the two required inputs for `actions/upload-artifact` -- `name` and `path` -- and adds the optional `retention-days` input. The `retention-days` value overrides the repository default but cannot exceed the limit set at the organization or enterprise level. Knowing that `retention-days` is a per-artifact override (not a global setting) and that it is bounded by higher-level policy is a testable distinction.

Pass build output between jobs using artifacts and job dependencies

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: dist/

  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: build-output
      - name: Deploy
        run: ./scripts/deploy.sh dist/

This two-job workflow demonstrates the canonical pattern for sharing data between jobs: the upstream job uploads an artifact, and the downstream job declares `needs: build` to guarantee execution order before downloading it by the same name. Both pieces are required -- omitting `needs` means the download job may start before the artifact exists. The `name` value on both actions must match exactly, making the artifact name the contract between the two jobs.

View and filter workflow run logs with the GitHub CLI

# View all logs for a specific run
gh run view 9876543210 --log

# View only failed step logs for a specific job
gh run view --job 1234567890 --log-failed

These CLI commands cover the two main programmatic log access patterns tested on the exam: viewing the full log stream for a run ID, and narrowing output to only failed steps within a specific job. The `--log-failed` flag is particularly useful for diagnosing failures without scrolling through successful step output. Note that read access to the repository is sufficient to run these commands, but write access is required to delete logs.

Common Pitfalls

Practitioners often assume artifacts and dependency caches are interchangeable because both store files on GitHub.

Caching is designed for reusing files that do not change often between runs, such as package dependencies, while artifacts are for saving job outputs to view or use after a workflow run ends.

A common assumption is that deleting a workflow run leaves its artifacts available for a separate cleanup step.

When a workflow run is deleted, all artifacts associated with that run are also deleted from storage immediately.

Developers sometimes expect that downloading the log archive after a partial re-run will contain all logs from the entire workflow run.

The downloaded archive only includes logs for the jobs that were re-run; logs for jobs from previous run attempts must be downloaded from those earlier attempts separately.

0 / 14

Author and maintain workflows · 40-45%

Consume workflows · 10-15%

Author and maintain actions · 15-20%

Manage GitHub Actions for the enterprise · 25-30%

14 summaries