[Wikid82]

What

Consolidates the four near-identical integration-test workflows into a single
.github/workflows/integration-tests.yml that builds the Charon image once
per run and fans out to parallel per-suite test jobs.

Before: cerberus-integration.yml, waf-integration.yml,
rate-limit-integration.yml, crowdsec-integration.yml — four workflows, one
job each, every one of them running ./.github/actions/build-charon-image
independently (~2-4 min same-repo, ~14 min on fork PRs) before its tests.

After: one build job runs the composite action once, docker saves
charon:local and uploads it as a 1-day run-scoped artifact; four suite jobs
(cerberus, waf, rate-limit, crowdsec) needs: build, docker load the
artifact, and run that suite's existing test + debug-dump + cleanup steps
verbatim. Net effect: the image build is paid once instead of 4×, and 3
runner slots are freed for the duration of the build.

Structure

build  (Build Charon image)         — build-charon-image composite ONCE → docker save → upload-artifact (retention 1d)
├── cerberus    (Cerberus Security Stack Integration)   needs: build → download-artifact + docker load → scripts/cerberus_integration.sh
├── waf         (Coraza WAF Integration)                needs: build → download-artifact + docker load → scripts/waf_integration.sh
├── rate-limit  (Rate Limiting Integration)             needs: build → download-artifact + docker load → scripts/rate_limit_integration.sh
└── crowdsec    (CrowdSec Bouncer Integration)          needs: build → download-artifact + docker load → skill-runner integration-test-crowdsec{,-startup}

Four explicit jobs, not a matrix: the suites are not uniform (crowdsec runs
two test suites; cerberus has an extra container-log artifact step; every
debug-dump inspects different ports/containers/volumes; every cleanup removes
different volumes). A matrix would need if: ladders on almost every step —
per the repo guidance, clarity beats DRY here.

Image hand-off mechanism

Uses the repo's existing cross-job pattern from security-pr.yml /
docker-build.yml: docker save + actions/upload-artifact in build,
actions/download-artifact + docker load in each suite job. Because build
and the suite jobs are in the same workflow run, no gh api artifact
hunting is needed (that machinery in security-pr.yml exists only for the
cross-workflow workflow_run hop). No GHCR scratch tag, no packages: write
— the artifact approach has no blocker at this image size with 1-day retention.

Trigger / concurrency

• Triggers: union of the four — workflow_dispatch + pull_request + push to
  main. (None of the four had paths: filters, so there is nothing to union
  there; all four still ran on every PR.) The unused workflow_dispatch
image_tag input — declared in all four old workflows but never referenced by
  any step — is dropped.
• Concurrency: ${{ github.workflow }}-${{ github.event_name }}-${{ github.ref }},
  cancel-in-progress: true — the four old groups were identical
  (…-${{ github.event.workflow_run.event || github.event_name }}-${{ github.event.workflow_run.head_branch || github.ref }});
  with no workflow_run trigger the workflow_run.* halves are always empty, so
  this is the same group with the dead fallbacks removed.

Timeouts

• build: timeout-minutes: 20 — unchanged; the fork-PR inline-compile floor
  (~14 min) still applies to the shared build. B6 comment preserved.
• Suite jobs: cerberus / waf / rate-limit at 12, crowdsec at 15
  (two suites) — the ~14 min inline-compile floor no longer applies to these now
  that the build is upstream; sized for test-only work.

Behavior change to flag for review

scripts/crowdsec_integration.sh (the deprecated wrapper the crowdsec job
reaches via skill-runner integration-test-crowdsec) ran docker build -t charon:local . unconditionally, so the old crowdsec-integration.yml
actually built the image twice (composite + script). It is now guarded behind
docker image inspect charon:local, matching its four sibling scripts
(crowdsec_startup_test.sh, cerberus/waf/rate_limit_integration.sh), so the
job consumes the pre-built artifact. Consequence: the crowdsec suite now runs
against the composite-built image (built with the ci: 'true' build-arg that
crowdsec-integration.yml already passed) rather than a plain script-built one.
Local runs are unaffected (no pre-existing charon:local → still builds).

The shared build job passes ci: 'true' (crowdsec's old value; the other
three passed the default 'false'). The CI build-arg only makes the GeoLite2
download fail-fast instead of retrying — no test-surface impact for waf /
cerberus / rate-limit.

No test or service/container was dropped. Every suite's test steps, debug-dump
step and cleanup step are copied across unchanged.

⚠️ Required-status-check rename (maintainer action)

The four old workflows' check names disappear and reappear as jobs under the new
Integration Tests workflow. Branch protection for main and development
must be updated — the check names themselves are unchanged, but the
identifying workflow is not, so GitHub treats them as new checks:

Old check (workflow)	New check (workflow)
Cerberus Security Stack Integration (Cerberus Integration)	Cerberus Security Stack Integration (Integration Tests)
Coraza WAF Integration (WAF integration)	Coraza WAF Integration (Integration Tests)
Rate Limiting Integration (Rate Limit integration)	Rate Limiting Integration (Integration Tests)
CrowdSec Bouncer Integration (CrowdSec Integration)	CrowdSec Bouncer Integration (Integration Tests)
(new)	Build Charon image (Integration Tests) — add as required

Notes

• Draft until the consolidated run is watched green on this branch with proof
  the build-charon-image composite runs exactly once and the suite jobs load
  the artifact (no rebuild).
• Stacked originally on feat/prebuilt-toolchain-image (feat(ci): prebuilt Caddy/CrowdSec toolchain image to fix Docker-build timeouts #1300); that PR has
  since merged to main, so this is rebased onto and targets main directly.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[github-actions]

✅ Supply Chain Verification Results

✅ PASSED

📦 SBOM Summary

• Components: 1769

🔍 Vulnerability Scan

Severity	Count
🔴 Critical	0
🟠 High	0
🟡 Medium	0
🟢 Low	0
Total	0

📎 Artifacts

• SBOM (CycloneDX JSON) and Grype results available in workflow artifacts

---

_{Generated by Supply Chain Verification workflow • View Details}