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

1. Create a project with .gitlab-ci.yml like the sample below
2. Run a pipeline
3. Observe that the job that refers to artifacts:paths with a value that looks across / with a doublestar glob (**) exceeds its timeout after waiting at Uploading artifacts...:

Uploading artifacts...
ERROR: Job failed: execution took longer than 3m0s seconds

The script exceeded the maximum execution time set for the job

Example .gitlab-ci.yml

.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 / hangs Uploading 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 / is CI_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.