-
Notifications
You must be signed in to change notification settings - Fork 611
Description
What happened?
Using the v4
tag broke automation that relies on the download-path
output always being populated. I've determined this to be a regression in v4.2.0
release that was just put out -- where if an inputs.pattern
matches no artifacts, the output is left empty instead of being populated.
This is a behavioral regression from a minor tag bump
What did you expect to happen?
I expect an output to still exist.
More formally, I expect no behavioral regressions when relying on a minor version update -- as per semantic versioning.
How can we reproduce it?
Run a workflow that uses a pattern
and matches on no artifacts. The output in v4.2.0
is empty, but in v4.1.*
and before is non-empty.
Complete example:
name: Demo regression
on:
pull_request:
jobs:
check-v4-2-0:
name: Check actions/download-artifact@v4.2.0
runs-on: ubuntu-latest
steps:
- name: Download Action
id: download
uses: actions/download-artifact@v4.2.0
with:
pattern: this-artifact-doesnt-exist
- name: Print Output
run: |
echo "v4.2.0 = ${{ steps.download.outputs.download-path }}" >> "${GITHUB_STEP_SUMMARY}"
check-v4-1-9:
name: Check actions/download-artifact@v4.1.9
runs-on: ubuntu-latest
steps:
- name: Download Action
id: download
uses: actions/download-artifact@v4.1.9
with:
pattern: this-artifact-doesnt-exist
- name: Print Output
run: |
echo "v4.1.9 = ${{ steps.download.outputs.download-path }}" >> "${GITHUB_STEP_SUMMARY}"
This produces in the STEP_SUMMARY
:
v4.2.0 =
and
v4.1.9 = /home/runner/work/test-repo/test-repo
Anything else we need to know?
Nothing more to say on the ticket, though I'm interested in whether this was a deliberate change, and whether the output-path
was not meant to be reliable when no artifacts are discovered? Was I relying on an implicit behavior I shouldn't have been?
What version of the action are you using?
v4.2.0
What are your runner environments?
linux
Are you on GitHub Enterprise Server? If so, what version?
No response