0

I have a step on my gitlabci that runs php code sniff. I used custom base image for this step.

This step exit with code 1 and failed the step.

I checked this with starting a container with my docker image. phpcs command is working like charm inside of base image.

It seems like gitlab-ci throw this code even if job is succeded. enter image description here

this is the output from gitlab-ci.

I checkout artifacts file row number and cli commands(inside docker container) row number. They are the same.

I could allow failure but this error is strange.

if [[ -f "phpstan.txt" && -s "phpstan.txt" ]]; then echo "exist and not empty"; 

I tried to allow failure inside bash script. I write a small custom control as above and place it after phpcs command inside my .gitlab-ci.yml. But job is failed before this script.

Gitlab version : v11.9.1

Docker image : custom based on php:7.2

My gitlab CI step :

phpcs:
    stage: analysis
    script:
        - phpcs --standard=PSR2 --extensions=php --severity=5 -s src | tee phpcs.txt
    artifacts:
        when: always
        expire_in: 1 week
        paths:
            - phpcs.txt

I think this is not about phpcs. I have a similar step (like phpcs) is named phpstan also an analsis mecahinism. It throws exactly same error on same line of script

rmznbyk 1
  • 1,104
  • 2
  • 13
  • 27
  • I forget to write. I also checked from here: https://gitlab.com/alvaropgl/gitlab-ci-playground/-/jobs/234662714 .This man runs same script with me. – rmznbyk 1 May 28 '20 at 11:05
  • It is indeed strange and should not be happening. Obviously something is out of order, you shouldn't have to work around it. See here, this issue seems similar but no fix yet https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3365 – devtoka May 28 '20 at 11:10
  • Oww sorry. Didn't see that. Thanks. – rmznbyk 1 May 28 '20 at 11:13
  • Could you try by removing `when: always`? – devtoka May 28 '20 at 11:29
  • I have pipelines currently working correctly with artifacts, only difference is I dont use that flag, which seems common in the linked issue. – devtoka May 28 '20 at 11:32

0 Answers0