- resolver: output both applications: (config/main.yml compose images) and images: (defaults/main.yml images) keyed by source_file - image_discovery: scan defaults/main.yml instead of vars/main.yml for images: - mirror_overrides: write mirror URLs to applications.*.compose.services.* (mirror_policy-aware) and images_overrides.*.* (always merged, if_missing) - roles/sys-ctl-hlth-csp, roles/test-e2e-playwright: move images: from vars/main.yml to defaults/main.yml for correct Ansible variable precedence - plugins/lookup/image.py: new Ansible lookup plugin that prefers images_overrides over role-local images defaults - docs: add artefact/image.md and artefact/mirror.md as SPOTs; add code/role/image.md contributor guide; link from ci.md - tests: update test_util, test_mirror_overrides; add test_resolver, test_publish (404/401 coverage), test_image (lookup plugin) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
5.1 KiB
Continuous Integration 🔄
This document describes the CI pipeline structure, entry points, and gates used in Infinito.Nexus.
Overview 🗺️
CI is triggered automatically on pull request events and push to latest. The pipeline is composed of reusable workflow files under .github/workflows/. The central coordinator is ci-orchestrator.yml, which is called by the entry workflows.
Entry Points 🚪
| Trigger | Workflow | Description |
|---|---|---|
| Pull request (opened, synchronize, reopened, ready_for_review) | entry-pull-request-change.yml | Detects PR scope and conditionally runs the full orchestrator |
Push to latest |
entry-push-latest.yml | Runs the full orchestrator on the main branch |
| Manual dispatch | entry-manual.yml | Allows triggering CI for a specific role or whitelist |
PR Scope Detection 🔎
Before the full pipeline runs, CI detects the scope of the PR based on the changed files and the branch prefix (see branch.md).
- Documentation-only and agent-only PRs MUST pass a lightweight gate without running the full orchestrator.
- All other scopes MUST run the full ci-orchestrator.yml.
- The branch prefix MUST match the detected scope, otherwise the
validate-pr-branch-prefixjob fails.
Pipeline Stages 🏗️
The orchestrator runs the following stages in order:
1. Fork Prerequisites ⏳
For fork PRs, CI waits for privileged images to be built by the pull_request_target event before proceeding. This ensures untrusted code never runs with elevated permissions.
2. Security 🛡️
- security-codeql.yml — static analysis via GitHub CodeQL.
3. Linting 🧹
All linting jobs run in parallel:
All four MUST pass the lint-gate before the pipeline continues.
4. CI Image Build 🐳
images-build-ci.yml builds Docker images for the target distributions (arch, debian, ubuntu, fedora, centos). These images are used by all subsequent test jobs.
5. Code Tests 🧪
Run in parallel after images are available:
All three MUST pass the test-code-gate.
6. Code Quality Gate 🚦
The code-quality-gate requires linting, code tests, and security checks to all pass before deploy tests are triggered.
7. DNS Tests 🌐
test-dns.yml validates DNS configuration across all target distributions.
8. Image Mirroring 🪞
images-mirror-missing.yml mirrors any missing upstream images in parallel with the DNS tests. See mirror.md for a full explanation of the mirroring architecture and naming convention. Authentication for GHCR is configured via repository secrets — see ghcr.md.
9. Deploy Tests 🚀
Run in parallel after DNS and mirroring:
- test-deploy-server.yml — server and
web-*roles - test-deploy-universal.yml — shared system roles
- test-deploy-workstation.yml — workstation and
desk-*roles
10. Installation Tests 📦
Run in parallel after the code quality gate:
Both MUST pass the test-install-gate.
11. Development Environment 🛠️
test-environment.yml validates the development environment setup.
12. Done 🏁
The final done job aggregates all deploy, install, and development gates. CI is considered green only when this job succeeds.
Concurrency 🔀
- PR pipelines use
cancel-in-progress: trueso only the newest run per PR and event type is active. - The orchestrator uses
cancel-in-progress: falseto avoid interrupting long-running deploy tests mid-flight.
Fork PRs 🍴
Fork PRs run under the pull_request event without write permissions. Privileged steps (image builds, package writes) run via pull_request_target after a maintainer review. The fork CI waits for those privileged images before proceeding. See pull-request.md for the contributor-facing fork workflow.