Files exists but can't be used to build artifacts.

Status changed to closed

Sorry. The GitLab CI can only archive files from directories relative to your build directory.

PLEASE document this ;)

Also, the actual bug here is the error message. It should tell the user that the path starts with / while it should be relative.

cc @tmaczukin :)

Just ran into this myself this needs to be documented and a better error message. Spent a day trying to figure this out.

This is bonkers.

changed milestone to %9.2

I made an account only for that bug in the 'documentary'. It cost my employer about 500 euros an my nerves! Please document this or fix the real bug.

Is there any upcoming changes that will address this and make it not relative to your build directory?

Been banging my head as well.

$ ls -l
total 11284
-rw-rw-rw-.   1 root     root         222 Apr 30 23:10 Dockerfile
-rw-rw-rw-.   1 root     root        8371 Apr  6 22:11 README.md
-rw-rw-rw-.   1 root     root     9816082 Apr  6 22:11 field_data.json
-rw-rw-rw-.   1 root     root        1509 Apr  6 22:11 glob.js
-rw-r--r--.   1 ftp_user ftp_user      95 May  5 02:09 message-results-latest-beta.json.enc
drwxr-xr-x. 133 ftp_user ftp_user    4096 May  1 01:02 node_modules
drwxr-xr-x.  13 ftp_user ftp_user    4096 May  5 02:09 cache_these
-rw-rw-rw-.   1 root     root     1130483 Apr 23 04:01 operators.csv
-rw-rw-rw-.   1 root     root       36358 Apr  6 22:11 package-lock.json
-rw-rw-rw-.   1 root     root         836 Apr  6 22:11 package.json
-rw-r--r--.   1 ftp_user ftp_user  193022 May  5 02:09 results-latest-beta.json
-rw-r--r--.   1 ftp_user ftp_user  193022 May  5 02:09 results-latest-beta.json.enc
drwxrwxrwx.   3 root     root        4096 May  5 01:45 src
drwxrwxrwx.   3 root     root        4096 Apr 23 20:33 test
-rw-rw-rw-.   1 root     root         519 Apr 17 21:00 test.sh
$ pwd
/usr/src/app
Creating cache s3_data...
WARNING: /usr/src/app/cache_these/: no matching files 
Archive is up to date!                             
Created cache
Uploading artifacts...
WARNING: /usr/src/app/*.json: no matching files    
Uploading artifacts to coordinator... ok

@coreynwops Have you already solved it? If you need help, post your pipeline here.

This must to be either documented or fixed. Is a really confusing warning message.

This is how I solve it for Go. Instead of copying it into GOPATH I symnlink it there, so everything is still accessable from the build directory.

variables:
  PKG_ROOT:  /go/src/gitlab.com/my/
  PKG_PATH: ${PKG_ROOT}project


.go_stuff: &go_stuff
  image: golang:1.10
  before_script:
  - mkdir -p ${PKG_ROOT}
  - ln -s /builds/my/project ${PKG_PATH} # <-- this is the important part. it needs to be symlinked, not copied
  - cd ${PKG_PATH}

package:
  <<: *go_stuff
  stage: package
  script:
  - make release
  artifacts:
    paths:
    - project-${CI_COMMIT_REF_NAME}.tar.gz

Whats the reasoning? It means for some bizarre reason best be known to someone I can't set up my virtual build environment to match a real one and KEEP it between stages. This is daft, it creates a huge amount of waste, a massive amount of extra overhead and then someone cant even be bothered to make a decent error message.

At the very very very very very very least document what the f********k you mean by 'your build directory'. On mine I have a file in /builds/mydir (call it fred.txt for now) I have tried artifacts as /builds/mydir/fred.txt and mydir/fred.txt and neither of these work, to me the directory says builds so which ****** directory are you actually talking about Wasting what little is left of my life on shit like this really doesnt appeal

@daveH1 you need to take a chill-pill its CE you can make PR(MR).

Hi Martin, probably do, my blood is right up now, lets face it it doesnt even consider it an error when it doesnt find anything to store away when I have told it... it just blunders on until it fails somewhere else

All I actually want is someone to explain just what files it will and wont archive in a proper way with examples. Then it would be nice to fix the BUG which means I (and from this thread plenty of others) cant use this functionality because it is restricted and badly documented.

I am going to have to revert back to dragging zip files back off amazon at EACH stage and unzipping them, of not being able to parallel builds up because of the number of accesses to amazon I need. Ridiculous

mentioned in commit 588adc19

mentioned in commit b11adc8a

mentioned in commit 8788fb92

ok, it is https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6838

now what? I still see

Uploading artifacts...
WARNING: /go/src/myapp: no matching files         
ERROR: No files to upload                          
Job succeeded

For anyone who is still facing this issue, in gitlab ce 11.6 the warning is still very cryptic which let me to this issue. The folder you specify in your gitlab-ci.yml file:

artifacts:
    paths:
    - build/

Is relative to /builds/$CI_PROJECT_PATH/. So in my case the artifacts would have to be in /builds/$CI_PROJECT_PATH/build

You saved hours of my life, thank you!

@_joost solution worked for me. The important thing is to understand the folder artifact uses is your project folder. so you need to give path relative to that folder. In my case (dotnet core) I used the following path /bin/Debug/netcoreapp2.2/ The path which it uses is /builds/{username}/{repositoryname} as base path. So my artifacts were in /builds/aceinthedeck/myproject/bin/Debug/netcoreapp2.2/

I hope it helps someone.

I'm having the same issue.

I was suffering this problem for Holly 1 week... we need more documentation and the proper way to fix this bloody problem.

Hello, is there anybody else who have come across the similar sitution?

$ ls ./test -al
total 76796
drwxr-xr-x    2 root     root          4096 Feb 24 11:45 .
drwxrwxrwx    4 root     root          4096 Feb 24 11:45 ..
-rw-r--r--    1 root     root      78618624 Feb 24 11:45 image.tar
Uploading artifacts...
WARNING: test/: no matching files                  
ERROR: No files to upload                          
Job succeeded

Tested on Gitlab.com

Still doesn't accept absolute paths. If you want to keep it that way, please document it with a "cannot use absolute paths" message or something similar.

mentioned in issue gitlab-runner#4060

@clovis-ai That's already documented in the artifacts part of the docs (https://docs.gitlab.com/ce/ci/yaml/README.html#artifacts).

artifacts:paths

You can only use paths that are within the project workspace.

Just read the fine manual. :)

@pmatos still though, the error message is misleading. It should say "cannot use absolute paths" instead of saying "file not found". And, it's as easy as checking if the first letter is a /, it's not a difficult change

mentioned in commit gartnera/distrobuilder-bin@60d02de2

Well, I solved using this workaround:

package:
  image: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}
  stage: package
  variables:
    GIT_STRATEGY: none
    DEBEMAIL: ${GITLAB_USER_EMAIL}
    DEBFULLNAME: ${GITLAB_USER_NAME}
  artifacts:
    paths:
      - debian_package/
    expire_in: 3 day
  script:
    # The magic is here:
    - PACKAGE_PATH="${PWD}/debian_package/"
    - cd ${APP_HOME}/package
    - debchange --distribution stable --package=app --newversion="$(date +%Y%m%d.%H%M%S)" "auto release"
    - dpkg-buildpackage -us -uc
    - mkdir -pv $PACKAGE_PATH
    # Move everything to package path and be happy
    - mv -v ${APP_HOME}/app* $PACKAGE_PATH

For me, this document wasn't fixed either. I ran into it and, like most, spent a day or so figuring it out. Wasted time or, considering the community size, wasted years.

mentioned in commit wtm/a-physics-definitive@5c0ce8ae

Why is this marked as closed, @ayufan ? I ran into this bug just today, the error message "no matching files" is very clearly factually incorrect and a bug.

The documentation says that an enhancement is discussed here, so why is this issue closed?

mentioned in commit jurafejfar/pg_bug@0f844301

Bug still appearing in 12.2.0-ee. I tried with and without the current directory prefix ./, no luck whatsoever.

$ echo "values-$SUB_COMPONENT.yaml"
values-my-component.yaml
$ echo -e "  ${YAML_TAG}:\n    image:\n      tag: ${image_name}" > ./values-$SUB_COMPONENT.yaml
$ cat ./values-$SUB_COMPONENT.yaml
  service:
    image:
      tag: 0.6.1-227661c7
$ ls
Dockerfile
docker-build.sh
docker-compose.yml
docker-run.sh
storage-targets.xml
values-my-component.yaml
my-component.jar
Uploading artifacts...
WARNING: ./values-my-component.yaml: no matching files 
ERROR: No files to upload

mentioned in commit DOMjudge/checktestdata@7f11d43a

experiencing the same thing, anyone know how to fix this ?

In our CI pipeline, we need to move the project out of the initial build directory and into a specific user's home directory. This is done due to various permissions issues and to mirror our production environment. As an application level restraint, this can't really be worked around. After reading that the artifacts need to be in the initial build directory to be picked up (as pointed out by @_joost above), I decided to try to copy the files back into the initial build directory at the end of the script before re-tooling our entire project. The following simplified gitlab-ci.yml roughly shows how the after_script section can be used to do this, and allow the files to be picked up correctly.

image: ubuntu/xenial
stages: test

before_script:

    # Move project to test user
    - mv /builds/group/repo/* /home/testuser
    - chown -R testuser:www-data /home/testuser

after_script:

    # Move logs back to build dir so they can be picked up as artifacts
    - mkdir /builds/group/repo/logs
    - mv /home/testuser/logs/* /builds/group/repo/logs

test: 
    stage: test
    artifacts:
        when: always
        paths:
            - logs/

    script:

        # Test as testuser
        - su - testuser -c './tests/runTests.sh'

# etc for more stages

/builds/group/repo is the initial directory, so /builds/group/repo/logs becomes just logs/ in the eyes of the artifacts path.

I would assume you could also either symlink the files back into the initial directory to avoid additional copies/moves, or symlink the build into wherever it needs to go instead of moving the files directly, as we do in before_script, to achieve the same effect. Additionally, in our case, using after_script is preferable to sticking something at the end of script, since we have multiple parallel tasks running in our tests, and any errors that occur during script cause our CI process to immediately halt and ignore the rest of the script section. after_script ensures that the logs are always in place to be picked up, whether on a successful or failed run.

Hopefully this helps someone else not spend hours trying to figure this out.

build-binary:
  image: golang:1.12
  stage: build_binary
  script:
    - go build -o <binary_name> 
    - mv ./<binary_name> ${CI_PROJECT_DIR}
  only:
    - development
  allow_failure: false
  artifacts:
    paths:
      - ./<binary_name>

hope this will help

script:
  - docker run --rm -v $(pwd)/target:/home 
   $IMAGE_LABEL_JAVA/$IMAGE_LABEL_JAVA:$CI_COMMIT_REF_NAME-$COMMIT_TIME bash -c 
   "cd /home; java -jar test-0.0.1-SNAPSHOT.jar"
  - ls -la $(pwd)/target  
artifacts:  
  paths:  
  - $(pwd)/target/*.html  
  expire_in: 1 week

Can someone please help me how can I make this artifactory work in this case ? I am mounting the $(pwd)/target folder that contains my report{timestamp}.html page. When i am trying to give this path it says file not found.How can i make this work ?

It started working using this

    - mkdir $CI_PROJECT_DIR/report
    - cp -r $(pwd)/target/*.html $CI_PROJECT_DIR/report
    - ls -la $CI_PROJECT_DIR/report
  artifacts:
    paths:
    - report/*.html

This one worked after trying 10 other solutions.

same for me, took a full day until tried this solution. Thank you

tyvm, same solution worked 4 me

Just for clarification. It has nothing to do with absolute or relative paths as this works

stages:
  - test

test:
  stage: test
  script:
    - touch `pwd`/test
  artifacts:
    when: always
    paths:
      - /builds/teamparallax/gitops/test-pipeline/test

Thanks @akaavinash0 your solution worked for me.

I don't get it, the file for me is in $CI_PROJECT_DIR and then I say:

  artifacts:
    reports:
      cobertura: coverage.xml

But it can't find the file?

I turn it into: $CI_PROJECT_DIR/coverage.xml and it still can't find the file.

@alpercugun I think the file needs to be in the list of artifact paths as well.

artifacts:
  paths:
    coverage.xml
  reports:
    junit: coverage.xml

Yeah this is crazy!
Apparently

    - mv ./myFile.txt ${CI_PROJECT_DIR}

did the trick 🤯

Now I just wonder - is that ${CI_PROJECT_DIR} just one directory for the whole project or is it specific to the job / pipeline? Because otherwise I fear concurrent pipelines overwriting each other with regards to that file... no?

Best Jannis

I ran into this issue the other day. In the end the solution looked like this for me:

    - pwd
   artifacts:
    when: always
    paths:
      - ${CI_PROJECT_DIR}/frontend/e2e/cypress/videos/**/*.mp4
      - ${CI_PROJECT_DIR}/frontend/e2e/cypress/screenshots/**/*.png
    expire_in: 2 days

This is a mono-repo and frontend is a folder in the root project folder. Should it be confusing where you actually are use the "-pwd" (or an equivalent for your OS) in the scripts section to see exactly where you are. The CI_PROJECT_DIR will be part of the path.

Hope this helps!

Best, Mario.

Use absolute path resolve my issue.

cache: &global_cache
  key: "$CI_COMMIT_REF_SLUG"
  paths:
    - "$pwd\\angular\\node_modules\\"
  policy: pull

The issue still persists. I am on GitLab.com and we have a pipeline job that builds a Java application:

The job is defined like this:

build:
  stage: build
  script:
    - ./gradlew clean build --stacktrace -x integrationTest -Pversion=$VERSION
    - pwd
    - find elab-service/build/libs -name *.jar
  artifacts:
    paths:
      - 'elab-service/build/libs/elab-service-*-all.jar'

And the Job output is following:

...
$ pwd
/builds/gennet-elab/elab-service
$ find elab-service/build/libs -name *.jar
elab-service/build/libs/elab-service.jar
elab-service/build/libs/elab-service-runner.jar
elab-service/build/libs/elab-service-all.jar
...
Uploading artifacts...
WARNING: elab-service/build/libs/elab-service-*-all.jar: no matching files 
ERROR: No files to upload                          
...

I checked, double/checked and triple checked and it seems the job definition is all correct:

it is a relative path
the file atualy exists
the wildcard actually matches the build artifact

But the Job still appears to fail the artifact

3rd statement is false, you don't have elab-service--all.jar here, only elab-service-all.jar

Yes, I noticed that. ️

mentioned in merge request gitlab-runner!3079 (merged)

Can we please get a better error message on this? The current one is very confusing when the file exists, but it just wont upload

This still annoys me to this day.. Why can't this behave like scripts in Gitlab CI. Starting from the project directory itself. it creates confusion when people do ls file is there but artifacts can't find it.

Its more about consistency in Gitlab CI when it comes to paths. Also in documentation the term "relative to the repository where the job was created." can be a bit confusing as many people don't get to the technical detail and think that where scripts are ran (the project directory) is where my CI job is created. I do get that the documentation is accurate, However my main complain is that its inconsistent. Make path behavior of Artifacts identical to path behavior of the scripts.

#Consistency

Solution that I suggest :

Also if this is not possible now.. as i do agree in many cases artifacts like JUnit etc are generated on the relative directory. I would recommend to have a keyword for specifying that you want artifact to be run from the project directory.

This seems to be the best solution, as existing CI jobs will not break as current behavior can remain the default behavior.

somehow, even with gitlab 14.8, this issue still exists. to make things even bizarre, it always works from the main (develop), however, on and off would throw alert "no matching files" from any merge request pipeline.

this is the setup:

build:
 stage: build
 script: 
  - mvn package
  - find . -type f -path '*/target/*.jar' # this shows the list of jars
 artifacts:
   paths:
      - ./*/target/*.jar'  # this only works in main branch, breaks on and off from other pipelines

Because herokuish is compiling the sources etc in /tmp/build, and immediately cleans up that location after the build, the best setup is to put in your gradle.build the locations where you would like to store your artifacts outside that temporary location.

So put in your gradle.build for unit and jacoco tests.

test {
  if(System.getenv('CI_PROJECT_DIR')) {
    reports.junitXml.destination = file("$System.env.CI_PROJECT_DIR/build/test-results/test/")
  }
  finalizedBy jacocoTestReport
}

jacocoTestReport {
  reports {
    xml.required = true
    if(System.getenv('CI_PROJECT_DIR')) {
      xml.outputLocation = file("$System.env.CI_PROJECT_DIR/build/reports/jacoco/test/jacocoTestReport.xml")
    }
  }
}

And put in your gitlab-ci.yml file.

test:
  variables:
    DISABLE_SPRING_DATASOURCE_URL: "true"
  script:
    - |
    - cp -R . /tmp/app
    - /bin/herokuish buildpack test
  artifacts:
    when: always
    paths:
      - build/reports/jacoco/test/jacocoTestReport.xml
    reports:
      junit: build/test-results/test/**/TEST-*.xml

Now GitLab is able to find your artifacts and upload them for you.

mentioned in merge request gitaly!4586 (closed)

mentioned in merge request gitlab!90867 (closed)

To bypass the problem you can use the full path

{CI_PROJECT_DIR}/

{FILE_TO_UPLOAD}

@zopar This does not work at least on 1.15.1.

Dear GitLab team, thanks for fixing this.

I would however ask you to take care of such issues differently in the future: Pulling a version that has already been released is adversely affecting everyone who already has this version installed.

Especially now, as more and more people and organizations are using tools to automatically update their dependencies, pulling an existing version breaks existing configurations (and not only the tool itself).

This affected both the OCI image of the runner and the helm chart for the runners (of which version 0.42.1 has been deleted).

In case this occurs again, please either release a new version with a bug fix or re-release the older version with a bumped patch version. This would have led to a new version 1.15.2 being released, making resolution of this easier in multiple ways:

Automated systems would have picked up the new version and (at least in some cases) automatically deployed it, leading to some organizations not having been affected at all or the issue being resolved automatically
Pulling the version led to broken configurations for every organization pinning versions as 1.15.1 was suddenly unavailable. In the case of a new version (1.15.2) being released, the bug would still have occured for people with 1.15.1, but their configuration would have been reproducible.
Pointing latest to an older version only fixes the issue for configurations that do not pin versions, which is discouraged anyway - pointing to latest does not ensure a reproducible setup.

Again, thanks for resolving this issue and I hope you take my points above into consideration to update the process.

Pipeline newbie here. Still got issues with finding my artifact.

    - mkdir $CI_PROJECT_DIR/artifact
    - cp -r $CI_PROJECT_DIR/target/*.jar $CI_PROJECT_DIR/artifact
    - ls -la $CI_PROJECT_DIR/artifact
  artifacts:
    paths:
      - artifact/*.jar

What am I doing wrong? I relocated my artifact file from the target to the artifact folder.

Files exists but can't be used to build artifacts.

Designs

Child items ...

Activity