On Wed, 21 Oct 2026 at 03:41, Brian Cain <[email protected]> wrote: > > > On 10/20/2026 6:16 PM, Pierrick Bouvier wrote: > > When merging PR on the project, it's possible to observe failures on CI > > that can be related to sporadic test failures or infrastructure issues > > (pod eviction with Kubernetes). As a result, it adds latency on the > > process and workload for our top maintainers. > > > > This patch sets an automatic retry (supported by gitlab out of the box), > > so failing jobs are automatically retriggered. > > > > It's important to note that in case there is a real test or build > > failure, concerned jobs will run a second time, and fail again. That > > said, it happens seldomly since sub maintainers are supposed to test for > > this before sending it. Also, the retry is limited to the job that > > failed, so it should be cheap in terms of CI minutes. > > Will this effectively mask those flaky failures so that no one hears > about them? Is there a way to find out about them with something like a > weekly/monthly digest of failures?
Broadly speaking, it's already the case that flaky failures are masked. Random infra-type failures / random timeouts /etc are common enough that when I'm doing a merge CI run I will just hit the retry button without much deep investigation. In an ideal world we'd pull down the gitlab job history and look through it for cases of "job X failed running against commit hash Y, but we also saw job X succeed on commit hash Y" (i.e. the retry worked second time) and then check the failure logs for what kinds of things are intermittent like that. But that requires somebody to put in the work to do that analysis. Gitlab's own CI job history web UI is very bad and doesn't let you do even basic things like "show me just the history for job X". thanks -- PMM
