Integration Process

This document is a step-by-step how-to for module owners who want to integrate their own S-CORE module into the Reference Integration — whether for the first time, when bringing it back after an exclusion, or to make it part of the S-CORE releases in general.

It walks you through everything from registering the module in known_good.json over wiring it into the Bazel build, the showcases, the images and the CLI, up to adding it to the CI/CD pipelines and the consolidated reporting (documentation, coverage and verification reports).

What “integration” means here

The Reference Integration is a single Bazel (bzlmod) build that pulls every S-CORE module together at a defined commit, builds them against each other and runs their tests, showcases and reports.

Integrating a module is incremental: each step below builds on the previous one and extends the reach of your module a little further into the integration. You climb the ladder only as far as your module needs — a pure library may stop after it builds in-tree, while a module with a runnable example goes all the way to running on every target platform and being exercised by integration tests.

The chapters that follow walk this ladder in order. Stop at whatever rung makes sense for your module.

Prerequisites

Before you start, make sure that:

• Your module lives in its own GitHub repository under the eclipse-score organization and is a bzlmod module, i.e. it has a top-level MODULE.bazel with a module(name = "score_<your_module>") declaration.

• The module name follows the score_<name> convention (e.g. score_communication). The same name is used as the Bazel bazel_dep / repository name (@score_<name>//...).

• Your module is registered in the S-CORE Bazel registry so that it can be resolved as a bazel_dep during the integration.

• The module builds and tests pass standalone on all four currently supported target platforms: Linux x86_64, QNX 8 x86_64, Red Hat AutoSD x86_64 and EB corbos Linux (Safety Apps) aarch64.

• You know the commit hash you want to pin (the integration always pins an exact commit, never a floating branch).

The integration steps

Work through the chapters in order — each one extends the reach of your module a little further into the integration:

• 1. Step 1 — Adding module to reference integration
  • 1.1. 1.1 Register the module in known_good.json
  • 1.2. 1.2 Regenerate the Bazel module fragments
  • 1.3. 1.3 (optional) Add Bazel patches
  • 1.4. 1.4 CI checks that the module was added correctly
• 2. Step 2 — Join the documentation and process-compliance checks
• 3. Step 3 — Get compiled and unit-tested on the default platform
  • 3.1. What you can tune from known_good.json
• 4. Step 4 — Get built and tested on the target platforms
  • 4.1. Run any image locally in QEMU
  • 4.2. Two ways to get your module onto the images
  • 4.3. Add a runtime showcase
  • 4.4. Add a binary directly to an image
• 5. Step 5 — Add component tests
• 6. Step 6 — Add feature integration tests
  • 6.1. Two test frameworks
• 7. Step 7 — Add coverage and verification reports
  • 7.1. How coverage is collected
  • 7.2. Where the results are exported
  • 7.3. C++ coverage
  • 7.4. Rust coverage
  • 7.5. Verification & status reports
• 8. Step 8 — Code quality
  • 8.1. What runs today
  • 8.2. Generated reports
• 9. Checklist
• 10. Reference
  • 10.1. CI checks
  • 10.2. Reports