Repository navigation
Keep network services CI quick and inside its limits #867
Description
Summary
Every pull request here waits for CI. The required check, ci / Build and test, ran close to the 30-minute limit of the shared workflow that runs it, so one slow runner could block every merge (#837). It now finishes well inside that limit. The two end-to-end workflows gate no merge, but each one holds a runner for 18 to 25 minutes on every push to main and on pull requests.
Goal
Every check gives its answer well inside its limit, and the end-to-end workflows hold a runner for less time. Each step is measured before and after it merges.
Done
These changes are merged. Each one follows a practice that exists already.
| change | the practice it follows |
|---|---|
| #845 gave the test run 25 minutes while the suite was slow | a bridge until the suite was faster; #848 removed it |
| #848 starts the controller package's API servers once, not once per test | one test environment per package, as kubebuilder's suite_test.go does |
| #849 runs the suite once, in the required check, in place of a second run in the Tests workflow | one authoritative unit suite per pull request, as in datum-cloud/dns-operator#458 |
#863 runs the suite through make test-suite and reads the envtest versions from go.mod |
kubebuilder's scaffold Makefile |
| #853 installs the end-to-end tools from release binaries, each checked against its SHA-256 | datum-cloud/dns-operator#433 |
Current state
These are the green runs on main between the merges of #853 and #863 (2026-11-04 15:04Z to 2026-11-05 10:02Z). All of them ran on GitHub-hosted ubuntu-latest.
| check | time on a runner | where the time goes |
|---|---|---|
ci / Build and test, required |
6 min 16 s to 7 min 16 s, for example run 42007412951 | the unit and envtest suite |
| E2E Tests | 23 min 28 s to 24 min 41 s, for example run 42007412565 | the environment's bring-up, 10 to 11 min; the suite, 12 min 49 s to 13 min 11 s |
| Federated E2E | 17 min 51 s to 19 min 59 s, for example run 42007412398 | the bring-up, 10 to 11 min; the scenarios, 6 to 7 min |
In both end-to-end workflows the tools step takes 3 to 5 s.
Plan
Steps 1 to 4 go in this order, and each one is measured on repeated runs on main before the next one starts. Step 5 waits for none of them.
| step | what | owner | the criterion that decides it |
|---|---|---|---|
| 1 | Install the tools from checksum-pinned releases | done in #853 | the tools step takes seconds, not minutes |
| 2 | Bring the end-to-end environment up faster: keep the Go build cache, build the image while the clusters come up, and start Karmada beside Milo and IPAM | vvoytovych | the bring-up is shorter in both workflows, and a run with an empty cache is no slower |
| 3 | Find which end-to-end tests can run side by side | vvoytovych; the suite runs one test at a time by a decision of 2026-07-14 | a test runs beside others only when the reasons for that decision do not apply to it |
| 4 | Run the end-to-end workflows on a prewarmed self-hosted runner | the owners of Datum's CI runners | a pull request from a fork never reaches the runner, because GitHub advises against self-hosted runners for public repositories |
| 5 | Let Renovate update each pinned tool's version and checksum together | a decision: the shared Renovate preset, or this repository | one Renovate pull request moves a version and its checksum |
Scope
This covers the required check and the two end-to-end workflows. What the tests prove stays out: #353, #358, #402 and #434 cover that.
Acceptance criteria
- The required check finishes well inside its limit on a normal run (The required CI check runs close to its 30-minute limit #837).
- Each step is measured on repeated runs on
mainbefore and after it merges, and its issue records the result. - Each end-to-end workflow holds a runner for less time than in the table above, and a run with an empty cache is no slower.
- A new release of a pinned tool reaches this repository as one Renovate pull request that moves its version and its checksum together.
Activity