It would be nice if another follow-up task could download the build artifacts for tests without having to manually install a tool for downloading and extracting the artifacts:
.test_template: &test-template
alias: test
depends_on: [build]
artifact_download: # <---- Currently does not exist, it would be nice if it did
task: build # Not sure what is the best syntax/names/arguments here,
name: dist # that can be further discussed/changed ...
path: dist/*
test_script: >
tox --installpkg dist/*.whl -e lint,typecheck,test
linux_task:
matrix:
- name: test (Linux - 3.7)
container: {image: "python:3.7-bookworm"}
- name: test (Linux - 3.10)
container: {image: "python:3.10-bookworm"}
skip: $BRANCH !=~ "^(main|master)$"
- name: test (Linux - 3.12)
container: {image: "python:3.12-bookworm"}
- name: test (Linux - 3.13)
container: {image: "python:3.13-rc-bookworm"}
install_script:
- python -m pip install --upgrade pip tox pipx
<<: *test-template
mamba_task:
name: test (Linux - mambaforge)
container: {image: "condaforge/mambaforge"}
install_script: # Overwrite template
- mamba install -y pip pipx tox
<<: *test-template
macos_task:
name: test (macOS - brew)
macos_instance:
image: ghcr.io/cirruslabs/macos-monterey-xcode
env:
PATH: "/opt/homebrew/opt/python/libexec/bin:${PATH}"
brew_cache: {folder: "$HOME/Library/Caches/Homebrew"}
install_script: brew install python tox pipx
<<: *test-template
windows_task:
name: test (Windows - 3.12.5)
windows_container:
image: "cirrusci/windowsservercore:2019"
os_version: 2019
env:
CIRRUS_SHELL: bash
PATH: /c/Python312:/c/Python312/Scripts:/c/tools:${PATH}
install_script:
- choco install -y --no-progress python3 --version=3.12.5 --params "/NoLockdown"
- pip install --upgrade certifi
- python -m pip install -U pip tox pipx
<<: *test-template
Context
Currently it is possible to download artifacts manually, but that requires installing a couple of tools to:
Download the archive
Unpack/unzip the archive
Depending on the OS used for each task, you may need different tools to do that, and the installation methods also vary.
This makes it difficult to implement re-usable chunks of YAML and requires the developer to either write a bunch of conditionals or to verbosely handle each execution environment individually.
Having a YAML instruction that handles the download and the unpacking/unzipping of the artifact would facilitate that process and help to write more maintainable .cirrus.yaml files.
I suppose it could be possible to re-use some part of the implementation of the cache instruction for this new instruction because they would be doing more or less the same thing (downloading from an URL and unziping/untaring the archive somewhere).
Description
Would it be possible to provide an YAML instruction that downloads a build artifact previously uploaded in another task?
Let's suppose for example that a
build
task exists and uploads the build output as an artifact, for example:It would be nice if another follow-up task could download the build artifacts for tests without having to manually install a tool for downloading and extracting the artifacts:
Context
Currently it is possible to download artifacts manually, but that requires installing a couple of tools to:
Depending on the OS used for each task, you may need different tools to do that, and the installation methods also vary. This makes it difficult to implement re-usable chunks of YAML and requires the developer to either write a bunch of conditionals or to verbosely handle each execution environment individually.
Having a YAML instruction that handles the download and the unpacking/unzipping of the artifact would facilitate that process and help to write more maintainable
.cirrus.yaml
files.Anything Else
Please note that in the past, it would be possible to use the
cache
instructions to achieve something very similar to this. However since the change in the macOS host mentioned in https://github.com/cirruslabs/cirrus-ci-docs/issues/1291#issuecomment-2332459800, that is no longer effective for a multi-platform CI.I suppose it could be possible to re-use some part of the implementation of the
cache
instruction for this new instruction because they would be doing more or less the same thing (downloading from an URL and unziping/untaring the archive somewhere).