Add context for the interruptible flag for GitLab #301
Conversation
|
| Name | Link |
|---|---|
| 🔨 Latest commit | 29be98f |
AP-3333 GitLab Pipeline builds are stuck in a pending status once a new build runs
WhatIndeed is having an issue where they cannot run UI Review on their Merge Requests unless they want to do a ton of manual work to merge their MRs. They would like for us to send a status of cancelled or disabled to the status check in GitLab if a new build is run on a branch. The overall goal would be that when a new build is triggered in Chromatic for a feature branch, we already disable the build so that users can no longer accept or deny any changes. In addition to that, we should update the related CI status check for GitLab and Bitbucket if possible. GitHub does not have this issue because the concept of a Pipeline doesn't exist and we update status checks on the PR directly. WhyIn GitLab, there is typically an auto-cancel build if a new build is run on that branch. It is not working for Indeed and therefore, when a new Chromatic build is run, if the previous build did not have an accepted or denied status, the build in GitLab is stuck in a pending state and waiting for the Chromatic jobs and the associated status checks to be approved. This further complicates the problem for Indeed because in order to merge their MRs, they have to either get all of those builds on a branch Pipeline to pass, or go in and manually cancel each one. The manual cancelling is fine for them if there are only a couple pending builds. However, when they have 4, 5, …n number of builds, then they have to cancel each one before the MR can be merged. How<If you have ideas or feedback on specific solutions you can list them here. We'll refine this section during the product process. Feel free to leave this section off entirely> |
thafryer
requested review from
winkerVSbecks
and removed request for
jonniebigodes
winkerVSbecks
deleted the
reuben/ap-3333-gitlab-pipeline-builds-are-stuck-in-a-pending-status-once-a
branch
This change addresses an issue with GitLab CI pipelines.
In GitLab, a previous build on a branch will run indefinitely, even if a new build is published for the same branch.
The reason is that the Chromatic status checks don't resolve within the GitLab Pipeline.
This docs change explains to our users how to configure their GitLab CI to ensure they save time on CI build minutes and are not blocked by hanging builds.