Skip to main content
In this lesson, you’ll learn how to use the allow_failure keyword to ignore specific job failures and continue executing dependent jobs in your GitLab CI/CD pipeline. By default, if a job fails, all downstream jobs that needs it are skipped and the entire pipeline is marked as failed.
The image shows a GitLab CI/CD pipeline interface for a NodeJS project named "Solar System," indicating a failed pipeline due to a script failure in the "code_coverage" job.

​
What Is allow_failure?

According to the GitLab CI/CD YAML syntax reference, allow_failure is a boolean or a set of exit codes that determines whether a job failure should block the pipeline: 
job2:
  stage: test
  script:
    - execute_script_2
  allow_failure: true
With allow_failure: true, even if job2 exits with a non-zero status, the pipeline continues and is marked as passed with warnings.
The image shows a GitLab documentation page about the allow_failure keyword in CI/CD YAML syntax, explaining its use and default values. The sidebar contains navigation links for various GitLab documentation topics.
Setting allow_failure: true records job failures as warnings rather than hard errors, ensuring dependent jobs still execute.

​
Controlling Failures by Exit Code

You can restrict which exit codes are treated as allowed failures. Any exit code not listed will still fail the pipeline: 
test_job_1:
  script:
    - echo "This script exits with code 1, so the job fails."
    - exit 1
  allow_failure:
    exit_codes: [137]

test_job_2:
  script:
    - echo "This script exits with code 137, so the job is allowed to fail."
    - exit 137
  allow_failure:
    exit_codes:
      - 137
      - 255
Job NameAllowed Exit CodesActual Exit CodeOutcome
test_job_1[137]1Pipeline fails (exit code not allowed)
test_job_2[137, 255]137Failure allowed, pipeline continues with ⚠️
Only exit codes specified under allow_failure.exit_codes bypass pipeline failures. All other exit codes will mark the pipeline as failed.

​
Applying allow_failure to Your Pipeline

Update the existing code_coverage job so its failure is ignored and the dependent job still runs: 
code_coverage:
  stage: test
  image: node:17-alpine3.14
  before_script:
    - npm install
  script:
    - npm run coverage
  artifacts:
    name: Code-Coverage-Result
    when: always
    expire_in: 3 days
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml
  coverage: '/All files[^|]*|[^|]*\s+([\d.]+)/'
  allow_failure: true

sample-job:
  stage: test
  needs:
    - code_coverage
  image: node:17-alpine3.14
  script:
    - echo testing sample job
Commit and push this change to your feature branch. The sample-job will run even if code_coverage fails.
The image shows a GitLab CI/CD pipeline interface for a project named "Solar System NodeJS Pipeline," displaying job dependencies and statuses. The pipeline includes jobs like "code_coverage" and "unit_testing," with "sample-job" marked as passed.

​
Viewing the Pipeline Status

After updating your pipeline:
  • The overall status is passed but displays a warning icon (⚠️).
  • The code_coverage job shows “failed with warnings.”
  • Dependent jobs like sample-job still execute:
$ echo testing sample job
testing sample job
The image shows a GitLab CI/CD pipeline dashboard with various pipeline statuses, including warnings, failures, and passes. It includes details like pipeline IDs, branches, and execution times.

​
Accessing Coverage Artifacts

Since code_coverage produces a Cobertura XML report, download it even if the job fails:
  1. Navigate to CI/CD > Jobs and click the code_coverage job.
  2. In the sidebar, select Artifacts.
  3. Download cobertura-coverage.xml (available for 3 days).
The image shows a GitLab interface displaying a list of artifacts from various jobs, including details like file count, job names, sizes, and creation times. The sidebar includes navigation options for managing projects, pipelines, and artifacts.

​
References

Watch Video