WIP: Integration process documentation#266
Conversation
antonkri
requested review from
AlexanderLanin,
FScholPer,
MaximilianSoerenPollak,
PiotrKorkus,
dcalavrezo-qorix,
lurtz,
nradakovic,
opajonk and
pawelrutkaq
as code owners
Add step-by-step integration process documentation including module addition, documentation, unit tests, platforms, component tests, integration tests, reporting, and code quality steps, plus a checklist and reference.
antonkri
force-pushed
the
ankr_integration_process
branch
from
65b0ff6 to
c03f9bd
Compare
|
The created documentation from the pull request is available at: docu-html |
| ################### | ||
|
|
||
| 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** for the first time. |
There was a problem hiding this comment.
first time or bring back after exclusion.
or integrate in general to be a part of SCORE releases
| * The module builds and tests pass standalone on Linux ``x86_64``. | ||
| * You know the commit hash you want to pin (the integration always pins an exact | ||
| commit, never a floating branch). | ||
|
|
There was a problem hiding this comment.
missing step - module is registered in score bazel registry
| * 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>//...``). | ||
| * The module builds and tests pass standalone on Linux ``x86_64``. |
There was a problem hiding this comment.
we currently build all modules for Linux x86, QNX x86, QNX aarch64 - this is bare minimum
also showcases are additionally built with autosd and EB
| ``rust_coverage_report`` target for every module that declares ``rust`` in its | ||
| ``langs`` (skipped for C++-only modules). | ||
|
|
||
| Commit the regenerated files together with the ``known_good.json`` change. CI |
There was a problem hiding this comment.
also bazel lockfile needs to be regenerated and commited.
bazel mod deps --lockfile_mode=update
We have it only in table below as fix if fails but after adding new module this will happen in 100%.
|
|
||
| .. _patches: | ||
|
|
||
| 1.3 (optional) Add Bazel patches |
There was a problem hiding this comment.
highly preferred to not have it, especially for a new module - make a good impression ;)
| injected for this module (feature flags, config selections). | ||
| * ``metadata.exclude_test_targets`` — test targets that must **not** run | ||
| (flaky, environment-specific or not meaningful out-of-tree); they are passed as | ||
| ``-@score_my_module<target>`` exclusions. Supports wildcards such as |
There was a problem hiding this comment.
they are passed as -@score_my_module... but the user needs to write just //path/to:excluded_target
Its obvious if you open known_good and look at the content but not from this intruction
| by CI. This is the rung that turns a library into something that *runs* inside | ||
| the integration images. | ||
|
|
||
| The integration ships four target images, each built and tested by its own |
There was a problem hiding this comment.
we dont ship images - someone could read it as ready to flash files are attached to the artifacts.
We just offer a way to create them on your own
|
|
||
| .. _add_showcase: | ||
|
|
||
| 4.1 Add a runtime showcase |
There was a problem hiding this comment.
renders as 4.3 4.1 - looks weird
|
|
||
| .. _add_directly: | ||
|
|
||
| 4.2 Add a binary directly to an image |
There was a problem hiding this comment.
all of these are integrated in step 3 unit tests - if everything is working in step 3, no additional actions are needed here
| # ******************************************************************************* | ||
|
|
||
| ################### | ||
| Integration Process |
There was a problem hiding this comment.
We need some split between how to operate reference integration and the documentation generated by reference integration?! Since the docs generated by reference integration serve as documentation of a release, IMHO operational stuff should not be included there.
The docs should start with "this is the documentation for the score 0.8 reference integration/product; this is what it can do". And that should be the scope. Nothing else.
3 participants
Work in progress — this is a first version of the integration process documentation intended to be reviewed by the colleagues responsible for integration.
Summary
Adds step-by-step integration process documentation under
docs/integration_process/:step_1_add_module.rst– adding a modulestep_2_documentation.rst– documentationstep_3_unit_tests.rst– unit testsstep_4_platforms.rst– platformsstep_5_component_tests.rst– component testsstep_6_integration_tests.rst– integration testsstep_7_reporting.rst– reportingstep_8_code_quality.rst– code qualitychecklist.rst– checklistreference.rst– referenceintegration_process.rstNote
This is a WIP and a first draft. Feedback from the integration-responsible colleagues is very welcome.