How do I exit a gitlab pipeline early without failure?

user_15238060 0
Viewed 4140

I have a gitlab .gitlab-ci.yml pipeline where the first job makes a decision about whether the rest are executed. Neither choice is a “failure” in the “send email and alert everyone” sense. It simply does or doesn’t need to be done at that time.

I’m looking for the opposite of allow_failure: true which allows the pipeline to continue regardless of the exit status of the job. Instead, I want determine the continuation status.

Is there an easy or common way to do this? Or am I, once again, stuck with generating yaml files?

gitlab gitlab-ci
2 Answers

It seems like this is currently not possible to do so in "easy" way, see relevant issues:

I personally was going to suggest going DAG route with needs: and artifacts, but i actually liked Elan Ruusamäe approach, using dotenv to pass variables between stages. Here is his example:

this gave me an idea, that maybe combining dotenv and if $SOME_VARIABLE, you could run/skip a job. But it may not work if the all the evaluation is performed at pipeline creation time. this snippet is not tested.

https://docs.gitlab.com/ee/ci/variables/#inherit-cicd-variables

build:
  stage: build
  script:
    - echo "SKIP_BUILD=true" >> .env.skip
  artifacts:
    reports:
      dotenv: .env.skip

docker build:
  script: echo yadayada
  rules:
    - if: '$SKIP_BUILD != "true"'

This still requires to check for previous status in downstream pipelines and looks pretty hacky, but at least not as hacky as grepping through some text files.

Since dotenv will likely not work in rules section, previous will have to be converted to something like:

build:
  stage: build
  script:
    - echo "SKIP_BUILD=true" >> .env.skip
  artifacts:
    reports:
      dotenv: .env.skip

docker build:
  script:
    - [ "$SKIP_BUILD" = true ] && exit 0
    - your_stuff_here
  dependencies:
    - build

See also: https://docs.gitlab.com/ee/ci/variables/README.html#pass-an-environment-variable-to-another-job

user_30660810

I don't care for the variable approach for two reasons. First, all of those jobs still get scheduled and run. And second, since they get scheduled and run, the UI doesn't make any visual distinction.

What I've ended up doing is splitting the pipeline into two passes. First pass makes the decision and (optionally) calls the second, via curl, with local variables used to distinguish between them.

It has the down side of adding extra pipelines to the pipelines UI page but they all succeed in the normal use case. So no extra email to the company.

I've also posted a feature request to make this a normal use case.

user_152380600
Related