Sharing Data Between Jobs With Artifacts
Jobs run on separate machines, so to pass a build from one job to another you upload it as an artifact.
Because each job gets a fresh, isolated runner, a file created in one job does not exist in the next. Artifacts solve this: you upload files in one job and download them in another. This lesson shows the upload/download pattern and when to use it.
The problem artifacts solve
Imagine a build job that compiles your app and a separate deploy job that ships it. The deploy job starts on a clean runner with none of the build output. Artifacts bridge that gap: the build job uploads its output, and the deploy job downloads it, even though they ran on different machines.
Uploading an artifact
Use actions/upload-artifact to store files under a name. Anything in the given path is bundled and kept by GitHub for later retrieval.
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm run build
- uses: actions/upload-artifact@v4
with:
name: dist
path: dist/Downloading it in a later job
A downstream job uses needs to wait for the build, then actions/download-artifact to pull the files in. The downloaded files appear on its runner exactly as uploaded.
deploy:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/download-artifact@v4
with:
name: dist
path: dist/
- run: ./deploy.sh dist/Things to keep in mind
- Artifacts are also great for keeping test reports, logs, and coverage files for inspection.
- They count against storage and have a retention period - set
retention-daysto expire them sooner. - For passing a single small value (not a file) between jobs, use job
outputsinstead of an artifact. - Large artifacts take time to upload and download; only ship what the next job actually needs.
Key takeaways
- Artifacts move files between isolated jobs via upload and download.
- Pair
upload-artifact/download-artifactwithneedsto order the jobs. - Use job outputs for small values, and set retention to control storage.