Skip to content

Verify pipline status on master also in case of failures

Alessio Caiazza requested to merge passing-build-for-gitlab into master

What does this MR do and why?

When we started experimenting with the idea of delayed pipeline status check, we realized that we have some flakiness.

image https://thanos.gitlab.net/graph?g0.expr=sum(increase(delivery_auto_deploy_gitlab_pipeline_total%5B1h%5D))%20by%20(status)&g0.tab=0&g0.stacked=0&g0.range_input=4w&g0.max_source_resolution=0s&g0.deduplicate=1&g0.partial_response=0&g0.store_matches=%5B%5D

A commit is candidate to auto-deploy if is green on the default branch, however a new pipeline will start once we create the auto-deploy branch.

With a delayed check, the pipeline on the new branch can be red at the time of check.

In this merge request, we ensure that when a GitLab SHA has a failed pipeline, we also verify the status of the same commit on the default branch. With this change, the delayed check logic will behave exactly like the upfront check.

Related to gitlab-com/gl-infra/delivery#775 (closed)

Author Check-list

  • Has documentation been updated?
Edited by Alessio Caiazza

Merge request reports