Jobs timeout seeking artifacts when paths use doublestar glob and start at / (instead of CI_PROJECT_DIR)
Summary
When artifact:paths
uses a doublestar glob (**
) and points to a non-existent artifact outside $CI_PROJECT_DIR
the job hangs until the timeout is exceeded. This is inefficient.
- It should fail early with a message about the problem.
- It used to fail early. The customer who I am writing this on behalf of reports that this represents a change in behavior. GitLab team members with access to Zendesk can learn more in the ticket about an example where we believe this may have worked properly previously.
Steps to reproduce
- Create a project with
.gitlab-ci.yml
like the sample below - Run a pipeline
- Observe that the job that refers to
artifacts:paths
with a value that looks across/
with a doublestar glob (**
) exceeds its timeout after waiting atUploading artifacts...
:
Uploading artifacts...
ERROR: Job failed: execution took longer than 3m0s seconds
The script exceeded the maximum execution time set for the job
.gitlab-ci.yml
Example .gitlab-ci.yml
A job constructed like this is enough to reproduce the problem:
use empty variable:
timeout: 3 minutes
script:
- date
artifacts:
paths:
- ${EVALUTES_TO_ROOT_DIR}/**/doesnotexist.txt
Example Project
The doublestar-timeout project demonstrates the undesired behavior.
-
🔭 Observe that the job that refers to a file that exists with the doublestar glob (- ${CI_PROJECT_DIR}/**/exists.txt
does work. -
🔭 Observe that the job that refers to a file that does not exist with a doublestar glob that is within$CI_PROJECT_DIR
exits quickly with an error:
WARNING: /builds/tickets/repro-timeout-doublestar/**/doesnotexist.txt: no matching files. Ensure that the artifact path is relative to the working directory
-
🐛 Observe that the job that refers to a file that does not exist with a doublestar glob that looks across/
hangsUploading artifacts
and fails because it exceeds its timeout.
On one hand:
- Our documentation on artifacts notes that paths are relative to the project directory (
$CI_PROJECT_DIR
) and can’t directly link outside it.
However:
- We can handle this case more efficiently by exiting quickly and encouraging the user to ensure that the artifact path is relative to the working directory.
- The customer may open a feature proposal suggesting that we treat the path as if
/
isCI_PROJECT_DIR
. (If the customer asks for/var/log
, we would look for${CI_PROJECT_DIR}/var/log
.
What is the current bug behavior?
The job continues to run until the job's timeout is met.
What is the expected correct behavior?
An error message like the following should be provided immediately:
WARNING: }/**/doesnotexist.txt: no matching files. Ensure that the artifact path is relative to the working directory
ERROR: No files to upload
Relevant logs and/or screenshots
Environment description
- This happens on the shared Runners on GitLab.com.
config.toml contents
Add your configuration here
Used GitLab Runner version
This happens with these combinations of Runner version and executor:
Running with gitlab-runner 15.3.0~beta.42.gdb7789ca (db7789ca)
Preparing the "docker+machine" executor
Running with gitlab-runner 15.3.0 (bbcb5aba)
Preparing the "shell" executor
Running with gitlab-runner 15.1.0 (76984217)
Preparing the "kubernetes" executor
✅ Correct Behavior Observed in 14.8
The customer reports that they observed the desired behavior as recently as:
Running with gitlab-runner 14.8.0~beta.44.g57df0d52 (57df0d52)
Preparing the "docker+machine" executor
...using the shared Runners on gitlab.com
. Please see my notes in 323258 for more information if you are a GitLab team member with access to Zendesk.
Possible fixes
🔧 Workaround
Follow the documentation on artifacts, which notes that paths are relative to the project directory ($CI_PROJECT_DIR
) and can’t directly link outside it.