Skip to content

Ensure after_script is called for canceled jobs with new keyword

Release notes

Problem to Solve

It's possible to want a after_script step for a gitlab-ci.yml, where it's important that it always run. However, the current behavior of after_script is that if a build is canceled the cleanup stage is skipped (even though this does not appear to be the original intent: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/102#note_11619214).

Proposal

Backend, Step 1

NOTE: Gitlab communicates with the runner through the Runner API - resource :jobs endpoint.

A new keyword should be added to minimize the impacts to existing users so that they can opt-in the fix. See the following example:

job:
  after_script:
    script:
      - echo "Execute this command after the `script` section completes."
    when: always

Runner will receive the new keyword when: always via the API

Runner, Step 1

When the runner receives canceling status and job config when: always is set:

  • as usual, if the job is in either created or pending, it should transit directly to canceled and update the job to Gitlab. No after_script should be executed or no traces/artifacts should be uploaded.
  • if the job is running, it will abort the scripts, run the after_script and upload traces/artifacts. Once all is finished, it will transit to canceled and update the job to Gitlab

Backend, Step 2

  • introduce the canceling status
  • when the job is in canceling state, allow traces/artifacts to be uploaded only when when: always is set

Frontend

The main Cancel ❌ button on the Pipelines page should be a button for a graceful shutdown if when: always.

Backend, Step 3

  • when graceful cancel button is click, job should transit to canceling.

Intended users

User experience goal

When a user cancels a pipeline/job the after_script portion of jobs currently running should be executed.

Permissions and Security

  • Add expected impact to members with no access (0)
  • Add expected impact to Guest (10) members
  • Add expected impact to Reporter (20) members
  • Add expected impact to Developer (30) members
  • Add expected impact to Maintainer (40) members
  • Add expected impact to Owner (50) members

Documentation

  • This will require an update to the after_script section of the docs.

Availability & Testing

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

Links / references

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by Tianwen Chen