Release artifact is expired, although it is latest
Summary
This issue is a combination of three curious events we witnessed. We have a repo with a pipeline containing a needs
on a step of another repo. This normally works, but not for this specific combination since recently. The gitlab ci of both repo's have not been changed, and the artifacts should not be expired, but are.
- A pipeline step that needs an artifact from another repo fails silently when it needs expired artifacts when using relative paths
- The keep button or retriggering a pipeline does not make the tagged artifacts available again, or in other words: there is no way to make tagged artifacts available again except for creating a new tag.
- Expired release artifact.
Steps to reproduce
PROJECT_2 has a release tag vx.y.z. This released artifact is expired, and pressing the keep button does not change anything about its artifacts being available to other pipelines.
.gitlab-ci.yml
collect-latest:tools:
stage: collect
image: <DOCKER_IMAGE>
script:
- 'mv out/* artifacts/'
needs:
- project: <PROJECT_1>
job: release
ref: 'master'
artifacts: true
- project: <relative/path/to/PROJECT_2>
job: build:linux
ref: 'vx.y.z'
artifacts: true
artifacts:
name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME-$CI_PIPELINE_IID-$CI_COMMIT_SHORT_SHA"
paths:
- artifacts/
rules:
- if: $COLLECT_VERSION == "latest"
Actual behavior
- The job ignores the needs artifact silently when it is expired
- It cannot be made 'unexpired' again
- It expired a released artifact
Expected behavior
- The job does not ignore the needs artifact or fails when the needs artifact cannot be downloaded with a clear description why.
- The 'keep' button makes the artifact available again to other pipelines in the same project
- It should not expire the latest artifact of a tag
Relevant logs and/or screenshots
job log
Actual log:
$ eval "$CI_PRE_CLONE_SCRIPT"
Fetching changes with git depth set to 50...
Initialized empty Git repository in <REPO_NAME>
Created fresh repository.
Checking out 57e12c35 as <BRANCH-NAME>...
Skipping Git submodules setup
Downloading artifacts
00:02
Downloading artifacts for release (936271946)...
Downloading artifacts from coordinator... ok id=<ID> responseStatus=200 OK token=<TOKEN>
Expected log:
$ eval "$CI_PRE_CLONE_SCRIPT"
Fetching changes with git depth set to 50...
Initialized empty Git repository in <REPO_NAME>
Created fresh repository.
Checking out dfdb6ef9 as <BRANCH-NAME>...
Skipping Git submodules setup
Downloading artifacts
00:02
Downloading artifacts for build:linux (#########)...
Downloading artifacts from coordinator... ok id=<ID> responseStatus=200 OK token=<TOKEN>
Downloading artifacts for release (#########)...
Downloading artifacts from coordinator... ok id=<ID> responseStatus=200 OK token=<TOKEN>
Environment description
This happens on the gitlab shared runners.
config.toml contents
EMPTY
Used GitLab Runner version
Please run and paste the output of gitlab-runner --version
. If you are using
a Runner where you don't have access to, please paste at least the first lines
the from build log, like:
On the triggered (broken) job:
Running with gitlab-runner 13.7.0-rc1 (98e2e32d)
on docker-auto-scale ed2dce3a
Work-around
When using absolute https paths in 'needs', there is a clear error message that the artifacts are not available/expired.