2026-06-18 –, D0206 (capacity 154)
Most OpenShift developers saw the dreaded Tide retest many times. All jobs are green and for SOME REASON Tide decides to run everything again and now the PR will not merge for several hours. It is not a bug, it is a feature. What if the green jobs actually ran a month ago when the code was much different? They surely do not provide reliable signal for a merge decision. They need to be retested.
It is indeed a feature, but that feature comes at a cost. Retests take time. They cost money. What if we stopped doing them? What would we save, and what risk would we open ourselves to? I will explore that in this talk.
The talk aims to be of interest even to attendees not familiar with OpenShift CI and Tide. These attendees may find it useful as a case study of how OpenShift organization merges code at scale, how it sets up quality gates, and what factors and tradeoffs affect the developer experience in such a system.
I am a maintainer of Prow, a CI/CD system developed and used in Kubernetes community.
Currently a member of the Technical Release Team at Red Hat, I am building tools that enabled the OpenShift engineering organization to continuously, efficiently and effectively manage the product quality at scale, identifying product regressions over vast corpus of data signals like test results and performance metrics.