|
12 | 12 | # SPDX-License-Identifier: Apache-2.0 |
13 | 13 | # ******************************************************************************* |
14 | 14 |
|
| 15 | +################### |
15 | 16 | Integration Process |
16 | 17 | ################### |
| 18 | + |
| 19 | +This document is a step-by-step *how-to* for module owners who want to integrate |
| 20 | +their own S-CORE module into the **Reference Integration** — whether for the |
| 21 | +first time, when bringing it back after an exclusion, or to make it part of the |
| 22 | +S-CORE releases in general. |
| 23 | + |
| 24 | +It walks you through everything from registering the module in |
| 25 | +``known_good.json`` over wiring it into the Bazel build, the showcases, the |
| 26 | +images and the CLI, up to adding it to the CI/CD pipelines and the consolidated |
| 27 | +reporting (documentation, coverage and verification reports). |
| 28 | + |
| 29 | + |
| 30 | +What "integration" means here |
| 31 | +============================= |
| 32 | + |
| 33 | +The Reference Integration is a single `Bazel (bzlmod) <https://bazel.build/external/overview#bzlmod>`_ |
| 34 | +build that pulls every S-CORE module together at a defined commit, builds them |
| 35 | +against each other and runs their tests, showcases and reports. |
| 36 | + |
| 37 | +Integrating a module is **incremental**: each step below builds on the previous |
| 38 | +one and *extends the reach* of your module a little further into the |
| 39 | +integration. You climb the ladder only as far as your module needs — a pure |
| 40 | +library may stop after it builds in-tree, while a module with a runnable example |
| 41 | +goes all the way to running on every target platform and being exercised by |
| 42 | +integration tests. |
| 43 | + |
| 44 | +The chapters that follow walk this ladder in order. Stop at whatever rung makes |
| 45 | +sense for your module. |
| 46 | + |
| 47 | + |
| 48 | +Prerequisites |
| 49 | +============= |
| 50 | + |
| 51 | +Before you start, make sure that: |
| 52 | + |
| 53 | +* Your module lives in its own GitHub repository under the ``eclipse-score`` |
| 54 | + organization and is a **bzlmod module**, i.e. it has a top-level |
| 55 | + ``MODULE.bazel`` with a ``module(name = "score_<your_module>")`` declaration. |
| 56 | +* The module name follows the ``score_<name>`` convention (e.g. |
| 57 | + ``score_communication``). The same name is used as the Bazel |
| 58 | + ``bazel_dep`` / repository name (``@score_<name>//...``). |
| 59 | +* Your module is registered in the |
| 60 | + `S-CORE Bazel registry <https://github.com/eclipse-score/bazel_registry>`_ so |
| 61 | + that it can be resolved as a ``bazel_dep`` during the integration. |
| 62 | +* The module builds and tests pass standalone on all four currently supported |
| 63 | + target platforms: Linux ``x86_64``, QNX 8 ``x86_64``, Red Hat AutoSD |
| 64 | + ``x86_64`` and EB corbos Linux (Safety Apps) ``aarch64``. |
| 65 | +* You know the commit hash you want to pin (the integration always pins an exact |
| 66 | + commit, never a floating branch). |
| 67 | + |
| 68 | + |
| 69 | +The integration steps |
| 70 | +====================== |
| 71 | + |
| 72 | +Work through the chapters in order — each one extends the reach of your module a |
| 73 | +little further into the integration: |
| 74 | + |
| 75 | +.. toctree:: |
| 76 | + :maxdepth: 2 |
| 77 | + :numbered: |
| 78 | + |
| 79 | + step_1_add_module |
| 80 | + step_2_documentation |
| 81 | + step_3_unit_tests |
| 82 | + step_4_platforms |
| 83 | + step_5_component_tests |
| 84 | + step_6_integration_tests |
| 85 | + step_7_reporting |
| 86 | + step_8_code_quality |
| 87 | + checklist |
| 88 | + reference |
0 commit comments