CI compiler reuse and job budgets#

This page records the GitHub runner durations behind the Verify job limits and the benchmark compiler cache from #46 . The development guide describes the current procedure, and ADR-0002 records the decision and the rejected alternatives. These are budget measurements on shared runners, not benchmark results; no CI check compares them with a threshold.

Method#

Durations come from the started_at and completed_at timestamps of jobs and steps in the GitHub Actions jobs API. Only successful jobs are counted, including successful jobs in runs where another job failed or the run was cancelled; every step value is that step’s own duration. All jobs ran on ubuntu-latest standard runners; the measured runs after the change reported Ubuntu 24.04 on x86_64 in the compiler cache key. Medians of an even number of jobs are the mean of the two middle values. GitHub announced that ubuntu-latest moves to Ubuntu 26 from 2026-10-19; that changes the distribution release in the key, and these durations do not describe the new image. A matrix job is one of the ten runtime/JDK/Protobuf builds; the binary compatibility and development bundle jobs are reported as whole jobs.

Before compiler reuse#

The baseline covers every CI run and scheduled Verify run from 2026-09-19 to 2026-10-05 whose Verify workflow matched commit f5063f7, apart from the pinned version of the action that installs just. These 23 runs are 35434366511 , 35435340746 , 35440618065 , 35441056894 , 35442533077 , 35443577622 , 35443918300 , 35444041169 , 35447057022 , 35447360960 , 35448219934 , 35524618918 , 35524623214 , 35524628581 , 35524639121 , 35524641946 , 35524647119 , 35600464462 , 36335473491 , 36429785484 , 37219064508 , 37219079057 , 37323878801 . Every matrix job built the compiler from source, so each of these runs was cold for the compiler.

Compiler preparation took about a quarter of a median matrix job and repeated in all ten jobs of each run. One sampled pull request log split it into about 11 seconds of package installation, 5 seconds of download, extraction, and configuration, and 42 seconds of C++ build. The archive download varied more than the build. The slowest preparation steps, from 146 to 182 seconds, came from the three scheduled runs, and in the sampled scheduled job the download from archive.apache.org alone took about 75 seconds. The slowest native verification steps, from 171 to 228 seconds, occurred in three runs whose commits changed the POM: in all ten jobs of the main push that merged PR #51 , and in some jobs of two dependency-update PRs. Their logs had expired when this page was written, so the cause of those slower steps is not established.

After compiler reuse#

Two manual runs on the PR branch at commit c4bc8dc measured the cold and warm cache paths. That commit copied the built compiler into a separate cached directory and checked it a second time; the final layout caches the built file in place and checks it once, which removes less than a second from a cold job. The cold run 38119339196 found no entry; one job saved the checked compiler (about 2 MB), and the other nine logged that another job was creating the entry, without a warning annotation. The warm run 38119813575 restored that entry in every matrix job and skipped package installation, download, and the build.

The binary compatibility and development bundle jobs do not use the compiler; their maxima were 165 and 204 seconds across the two runs. A warm run removes the compiler preparation, a median of about 80 seconds, from each matrix job, or about 13 runner-minutes per CI run, and no longer depends on the archive download. The longest warm matrix job took 286 seconds, compared with 380 seconds in the cold run. A cold run costs the same compiler build as before, plus at most 2 seconds of identity, restore, and save steps; the API reports whole seconds.

A pull request run can restore entries saved on its own merge ref or on main, but not on the PR’s head branch. The first PR run 38120594823 found no entry for its merge ref: four matrix jobs built the compiler, the first of them to save created the entry, and the six jobs that reached the restore step afterwards used that entry. Later runs of the same PR restore that entry, and new PRs restore an entry once a main run has saved it.

Job limits#

The rule in the development guide gives these limits from the slowest successful durations above.

Issue #141 changed the binary compatibility job from one cell per Protobuf profile to one per artifact line, each building the jar with Protobuf 4 and also running it with Protobuf 3 tests. In pull-request run 40918680497 , the 2.x cell, which runs the suite four times, took 365 seconds, and the LTS cell took 242 seconds. That run still used a full verify for the Protobuf 3 build, which the final recipe replaces with a build through process-test-classes; twice its 2.x duration stays within the 15-minute limit.

Issue #140 removed the retained upgrade job, and the development bundle job now also runs baseline-upgrade, the API gate, and the compiled consumers on the bundle that it captured. In pull-request run 41195401814 , its LTS jobs took 291 and 301 seconds and its 2.x jobs 446 and 463 seconds, so twice that maximum rounds up to a 20-minute limit.

The release rehearsal job from issue #13 builds both artifact lines without tests, plus a third build that the release-line guard stops at validate; it resolves the release plugins, which the shared Maven entry does not hold, on every run. In pull-request runs 41192241047 , 41194651888 , and 41195572314 , it took 93, 106, and 87 seconds, so twice that maximum rounds up to a 5-minute limit.

The matrix limit keeps the cold-compiler maximum, because a key change or an evicted entry returns every job to the cold path. No measured job combined the slowest step of each kind, but even the sum of the per-step maxima, about 630 seconds including setup steps, stays within the 20-minute limit.