Enforce fast and resource-efficient pull-request feedback

[FelixTJDietrich]

What

Operate required pull-request CI as a developer-facing service with explicit latency and runner-efficiency objectives, robust regression detection, reliable cancellation of obsolete work, and no silently ignored workflow configuration.

Use supported GitHub APIs, native job summaries/timelines, cache-action diagnostics, JUnit reports, and Spring context metrics. Avoid building a custom analytics platform or presenting dependency wait as pure runner queue time.

Establish a rolling baseline from representative green PR runs and report separately:

• workflow creation to required-green;
• required-job execution duration;
• job creation-to-start delay, labeled as including dependency waiting where eligibility is unavailable;
• summed runner execution time and Docker runner time;
• cancelled/superseded work;
• full Spring starts, cumulative startup, and context-cache behavior.

Evaluate the runner impact of running Docker concurrently with verification. If contention is material, prefer accurate path filters, BuildKit caching, cancellation, or Docker-specific concurrency controls over restoring a broad Quality-to-Docker dependency.

Resolve actionable workflow warnings that indicate unsupported or ineffective configuration, including the ignored predicate-quantifier input, deprecated action runtimes, and Docker artifact-metadata warnings. Retain immutable commit pins and do not add permissions merely to silence warnings.

Why

#1523 reduced required workflow latency from 17m24s to 10m17s while preserving all verification, but one green run is not a service level. Integration and API/Database remain close to ten minutes, and parallel Docker builds trade lower elapsed time for greater instantaneous runner demand in an organization with limited capacity.

Metrics are useful only when they inform a budget or resource decision. The goal is predictable fast feedback without hiding work, overloading shared runners, or failing pull requests on one noisy hosted sample.

Initial objectives to validate against at least eight representative green runs:

Metric	Initial objective
Required workflow p50	≤10 minutes
Required workflow p95	≤11 minutes
Required server-job p95	≤10 minutes until #1527 lands
Storybook p95	≤5m30s
Superseded PR runs	cancelled
Unreviewed Spring context keys	zero
Sustained runner-time regression	detected and explained

References:

• DORA software delivery performance metrics
• Martin Fowler — Keep the Build Fast
• GitHub Actions concurrency
• GitHub Actions job dependencies
• Docker build-cache optimization
• Software Engineering at Google — Testing Overview

Done when

• At least eight representative green PR runs establish the initial rolling baseline.
• Required makespan, job execution, start/dependency delay, and total runner time are reported separately without manual log downloads.
• Rolling p50 and p95 values are visible and each collected metric has a documented decision it informs.
• Sustained regressions produce an actionable signal using a noise-resistant policy rather than failing on one slow runner.
• Superseded PR runs reliably cancel without affecting main or release workflows.
• Parallel Docker execution is evaluated for latency, peak demand, runner time, start delay, cancellation savings, and work spent before unrelated failures.
• Unsupported workflow inputs are removed or corrected; actionable runtime and artifact-metadata warnings are resolved without floating action tags or unjustified permissions.
• No required test, security, migration, or image-build confidence is removed to satisfy the budgets.
• Contributor documentation explains the service levels, regression response, and local profiling path.
• Budgets are reviewed and ratcheted after perf(ci): validate generated-client reuse across server verification #1527 creates stable server-job margin.

[FelixTJDietrich]

Implemented the actionable workflow and profiling improvements in #1530: unsupported configuration and deprecated runtimes are resolved, Docker's optional build-record warning is removed without additional permissions, and the Spring integration profile now reports rolling resource/context metrics and signals only after three consecutive regressions.

During implementation we pressure-tested the proposed custom pull-request performance report and decided not to ship it. A weekly Actions summary would duplicate GitHub's organization-level Actions metrics, create a second reporting surface, and lack a sufficiently clear owner and response loop. General workflow/job runtime, queue-time, failure-rate, and runner-usage analysis should use GitHub Actions metrics; repository-specific Spring, JFR, and JUnit diagnostics remain in CI profile.

The custom eight-run repository report and CI SLO enforcement described here are therefore not planned. #1527 now owns a self-contained eight-run observation window for validating #1529, without depending on permanent custom reporting infrastructure.

If the team later adopts a formal CI SLO, it should start with an explicit owner, review cadence, escalation policy, and evidence that GitHub's native metrics are insufficient.