Ask
26
@counted_315 ·

Measured 2,400 CI runs across 24 large projects: the median test workflow finishes in 2.2 minutes

Everyone talks about slow CI, so I measured what large open source projects actually run. The last 100 completed runs from 24 well-known repositories, split by workflow rather than lumped per repo.

24 repositories, 315 distinct workflows. That is thirteen each, and it was the first surprise: nobody has one pipeline any more.

The median test-shaped workflow takes 2.2 minutes. Automation workflows (labelling, stale bots, triage) take 0.2 minutes and are 14 percent of all runs.

The median is not the interesting part though. The tail is:

  • deno ci: 69.5 minutes
  • rust CI: 67.6
  • numpy sanitizer build: 30.5
  • prometheus CI: 28.2
  • rollup CI: 19.8

19 of 81 test workflows run over ten minutes. So most CI is fast and a fifth of it is where all the pain lives, which matches how people talk about it: nobody complains about the 2 minute job.

Retries, from run_attempt: 25 of 315 workflows contain at least one rerun. The concentration is what stands out: deno ci at 10 of 48 runs, tailwindcss Integration Tests at 9 of 43. Around a fifth of runs on those two, and zero on most others.

Caveat: this measures wall clock from run start to completion, so runner queue time is included. That is what a developer experiences, but it is not pure execution time.

11 answers Share
Report

Answering anonymously, a moderator will review it first.

  • @retry_button_addict · 2w ago · 2 replies

    The retry concentration is the finding I would pull out. A fifth of runs on two projects and near zero elsewhere means flakiness is not a fact of life, it is a property of specific suites.

    That is encouraging in a way people rarely frame it: if most large projects run at zero, the ones at 20 percent have a fixable problem rather than an inherent one.

    21
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @counted_315 · 2w ago

      Both of the high ones are integration suites hitting real services, which is the usual suspect and it is nice to see it fall out of the data.

      1
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
  • @monorepo_pain · 2w ago · 3 replies

    Thirteen workflows per repo sounds like sprawl and mostly it is not, it is the correct answer to a monorepo. You cannot run 40 packages' tests on every commit, so you split by path filter and each split becomes a workflow.

    The failure mode is not the count, it is when nobody can say which of the thirteen is the one that gates a merge. We had eleven and three of them were required, which nobody knew without opening branch protection settings.

    23
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @monorepo_pain · 2w ago

      Both work. What does not work is thirteen files that arrived one at a time without anyone drawing the graph.

      10
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
    • @one_workflow_only · 2w ago

      Counter-experience: we deliberately kept one workflow with internal jobs, and the thing it buys is that the dependency graph is in one file you can read. Thirteen files means the graph exists only in somebody's head.

      12
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
  • @queue_time_matters · 2w ago · 3 replies

    Including queue time is the right call and I would go further: it is the only number that matters to the person waiting.

    We spent a quarter optimising a test suite from 14 minutes to 9 and the perceived improvement was nothing, because peak-hours queue time was 6 minutes and we had not touched it. Moving to a larger runner pool did more for the team than the optimisation did.

    Measure what the developer waits for, then decide which half to attack.

    27
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @counted_315 · 2w ago

      Which also means these numbers are partly a statement about how well-provisioned these projects are, not only about their tests.

      14
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
    • @actions_bill_payer · 2w ago

      Larger runners cost more per minute and often less per run, and finance only ever sees the first number.

      11
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
  • @actions_bill_payer · 2w ago

    Two minutes median across 315 workflows is also a spending statement. Automation runs are cheap individually and there are a lot of them, and on a busy repository the stale bot and the labeller quietly add up to real minutes.

    Worth auditing once a year, not because it is large but because nobody ever looks.

    1
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
  • @one_workflow_only · 2w ago

    Nobody complains about the two minute job is the line I am stealing.

    1
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
  • @queue_time_matters · 2w ago

    What was the spread on the automation workflows? 0.2 median suggests some of them are basically instant.

    1
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report