Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 46,777
    • Issues 46,777
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,532
    • Merge requests 1,532
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #273157
Closed
Open
Issue created Oct 27, 2020 by Marius Bobin@mbobin0️⃣Maintainer0 of 6 checklist items completed0/6 checklist items

Enhance allow_failure to capture failure reasons

Release notes

Allow_failure keyword will prevent a failed job to fail an entire pipeline, previously allow_failure accepts only binary value (true or false), in this release, we enhanced the allow_failure keyword to accept different exit code of a job, this will allow you to have better control on when to prevent the pipeline to fail base on the job exits codes.

Problem to solve

We've had an internal meeting about how to proceed on #16733 (closed) and we feel like the issue is too broad and both of the proposals mentioned in there are complex and will affect the simplicity/reliability of the whole system. We should keep how we mark a build as failed or successful as simple as possible and if we can make it even more simple and even more reliable. But we should not change it in a way that it makes it more brittle and error prone.

The overall conclusion was to start with something simple that augments allow_failure to accept a list of exit codes for which the job will be marked as passed with warnings. Extra functionality can be built on top of this, like updating retry to use those reasons for its when policy.

Recording: https://www.youtube.com/watch?v=DiicryT-W9M

Intended users

User experience goal

Proposal

Implement exit_codes: integer or array for allow_failure::

test_job:
  script:
    - execute_script_that_will_fail 
# if the script exit code is 137 or 255 the job will allow to be failed and the pipeline will continue to run
  allow_failure:
    exit_codes: # User defined exit code
      - 137
      - 255
test_job:
  script:
    - execute_script_that_will_fail
  allow_failure:
    exit_codes: 137
  • Change the API to accept the exit code from the Runner
  • Change the Runner to send the exit code back to Rails
  • Implement YAML syntax changes
  • Use the exit code to flag the job as allowed to fail.

Further details

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited Dec 10, 2020 by Dov Hershkovitch
Assignee
Assign to
Time tracking