Several behavioral differences exist between Artifact actions `v3` and below vs `v4`. This document outlines common scenarios in `v3`, and how they would be handled in `v4`.
@ -142,3 +143,64 @@ jobs:
```
Note that this will create an _entirely_ new Artifact, with a different ID from the previous.
## Merging multiple artifacts
In `v3`, multiple uploads from multiple jobs could be done to the same Artifact. This would result in a single archive, which could be useful for sending to upstream systems outside of Actions via API or UI downloads.
Note that this will download all artifacts to a temporary directory and reupload them as a single artifact. For more information on inputs and other use cases for `actions/upload-artifact/merge@v4`, see [the action documentation](../merge/README.md).
Note: this actions can only merge artifacts created with actions/upload-artifact@v4+
This sub-action is a helper to merge multiple artifacts after they are created. To do so, it will download multiple artifacts to a temporary directory and reupload them as a single artifact.
For most cases, this may not be the most efficient solution. See [the migration docs](../docs/MIGRATION.md#multiple-uploads-to-the-same-named-artifact) on how to download multiple artifacts to the same directory on a runner. This action should only be necessary for cases where multiple artifacts will need to be downloaded outside the runner environment, like downloads via the UI or REST API.
### Inputs
```yaml
@ -60,4 +68,133 @@ Note: this actions can only merge artifacts created with actions/upload-artifact
## Examples
TODO(robherley): add examples
For each of these examples, assume we have a prior job matrix that generates three artifacts: `my-artifact-a`, `my-artifact-b` and `my-artifact-c`.
Each of the following examples will use the `needs: upload` as a prerequesite before any merging operations.
### Combining all artifacts in a workflow run
By default (with no inputs), calling this action will take all the artifacts in the workflow run and combined them into a single artifact called `merged-artifacts`:
```yaml
jobs:
# ... <uploadjob> ...
merge:
runs-on: ubuntu-latest
needs: upload
steps:
- name: Merge Artifacts
uses: actions/upload-artifact/merge@v4
```
This will result in an artifact called `merged-artifacts` with the following content:
```
.
∟ file-a.txt
∟ file-b.txt
∟ file-c.txt
```
To change the name of the artifact and filter on what artifacts are added, you can use the `name` and `pattern` inputs:
```yaml
jobs:
# ... <uploadjob> ...
merge:
runs-on: ubuntu-latest
needs: upload
steps:
- name: Merge Artifacts
uses: actions/upload-artifact/merge@v4
with:
name: my-amazing-merged-artifact
pattern: my-artifact-*
```
### Prefix directories in merged artifact
To prevent overwriting files in artifacts that may have the same name, you can use the `separate-directories` to prefix the extracted files with directories (named after the original artifact):
```yaml
jobs:
# ... <uploadjob> ...
merge:
runs-on: ubuntu-latest
needs: upload
steps:
- name: Merge Artifacts
uses: actions/upload-artifact/merge@v4
with:
separate-directories: true
```
This will result in the following artifact structure:
```
.
∟ my-artifact-a
∟ file-a.txt
∟ my-artifact-b
∟ file-b.txt
∟ my-artifact-c
∟ file-c.txt
```
### Deleting artifacts after merge
After merge, the old artifacts may no longer be required. To automatically delete them after they are merged into a new artifact, you can use `delete-merged` like so:
```yaml
jobs:
# ... <uploadjob> ...
merge:
runs-on: ubuntu-latest
needs: upload
steps:
- name: Merge Artifacts
uses: actions/upload-artifact/merge@v4
with:
delete-merged: true
```
After this runs, the matching artifact (`my-artifact-a`, `my-artifact-b` and `my-artifact-c`) will be merged.
### Retention and Compression Level
Similar to actions/upload-artifact, both [`retention-days`](../README.md#retention-period) and [`compression-level`](../README.md#altering-compressions-level-speed-v-size) are supported: