Skip to content

ci: split ci into a matrix job - #447

Open
BjoernKarma wants to merge 3 commits into
mainfrom
ci/matrix-build
Open

ci: split ci into a matrix job #447
BjoernKarma wants to merge 3 commits into
mainfrom
ci/matrix-build

Conversation

@BjoernKarma

@BjoernKarma BjoernKarma commented Jun 30, 2026

Copy link
Copy Markdown
Contributor

CI: Refactor per-module jobs into a matrix build

What changed

The ci.yaml workflow previously defined 22 separate top-level jobs — one per module — each calling reusable-go-ci.yaml individually. This PR replaces that repetitive structure with:

  • A single go_ci matrix job covering 19 modules (up to 6 running in parallel), with all per-module configuration encoded as matrix entries.
  • Two dedicated direct jobs (common, common_server) for modules with non-standard flags (e.g. run_build_image: false for the library-only common module).
  • One dedicated snapshotter job because it requires run_lint: false, which cannot be expressed in the shared matrix.
  • A new ci_summary job that aggregates all results and acts as a single aggregation point for branch protection rules.

Why this makes sense

Before After
22 individually written jobs 1 matrix + 3 special-case jobs
Adding a module = copy-pasting ~10 lines Adding a module = 4–5 line matrix entry
All jobs visible as separate top-level status checks Single CI Summary check aggregates everything
One failure could obscure others fail-fast: false — all modules run, all failures visible

What is preserved

  • All per-module flags (coverage_threshold, run_check_generated_files, lint_fail_on_issues, ko_build_path) are encoded in the matrix entries with the same values as before.
  • Internal test-before-build ordering inside reusable-go-ci.yaml is unchanged — each call still runs tests → build image.
  • Helm release path (common_server_helm) still depends on common_server and only runs on tag pushes.
  • No behavior change on PR, push to main, tag, schedule, or workflow_dispatch triggers.

Action required after merge

If branch protection rules reference specific job names from the old workflow (e.g. "Approval / Tests & Coverage for approval"), update them to reference CI Summary as the single required status check.

… jobs for special cases (common, common_server, snapshotter) so the current default behavior stays intact
@BjoernKarma BjoernKarma added the github_actions Pull requests that update GitHub Actions code label Jun 30, 2026
@BjoernKarma BjoernKarma self-assigned this Jul 6, 2026
@BjoernKarma
BjoernKarma marked this pull request as ready for review July 10, 2026 13:31
Copilot AI review requested due to automatic review settings July 10, 2026 13:31

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR refactors the repository’s main CI workflow by replacing many per-module reusable-workflow jobs with a single matrix-driven job, while keeping a few special cases as dedicated jobs. It reduces repetition in .github/workflows/ci.yaml and introduces a single “CI Summary” job intended to be used for branch protection aggregation.

Changes:

  • Replaced most per-module jobs with a go_ci matrix job (fail-fast disabled, max 6 in parallel) that calls reusable-go-ci.yaml with per-module parameters.
  • Kept dedicated jobs for common, common_server, and snapshotter, plus the tag-only common_server_helm release job.
  • Added a ci_summary job that summarizes results and fails the workflow if any required job fails (allowing common_server_helm to be skipped when not on tags).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

github_actions Pull requests that update GitHub Actions code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants