Repository navigation
Conversation
arkjedrz
requested review from
AlexanderLanin,
FScholPer,
MaximilianSoerenPollak,
PiotrKorkus,
antonkri,
dcalavrezo-qorix,
lurtz,
nradakovic,
opajonk and
pawelrutkaq
as code owners
October 27, 2026 11:49
|
The created documentation from the pull request is available at: docu-html |
depending modules to newest main updated modules: - kyron - persistency - test scenarios
Contributor
|
After bumping test scenarios, which required bump of its consumers (persistency and kyron) to newest main we have following problems:
|
* Add release-note agent, skill and generator; add v0.10 release note draft
Signed-off-by: Anton Krivoborodov <anton.krivoborodov@bmw.de>
* Format release-note scripts with ruff
Signed-off-by: Anton Krivoborodov <anton.krivoborodov@bmw.de>
* Remove session-specific details from release-note skill and agent
Signed-off-by: Anton Krivoborodov <anton.krivoborodov@bmw.de>
* Release note: list removed files as evidence, correct v0.10 content
Signed-off-by: Anton Krivoborodov <anton.krivoborodov@bmw.de>
* Release note: take the release date from the S-CORE milestone
Signed-off-by: Anton Krivoborodov <anton.krivoborodov@bmw.de>
* Release note: show draft or final state on top of the note
Signed-off-by: Anton Krivoborodov <anton.krivoborodov@bmw.de>
* Release note: set the final state explicitly with --final
Signed-off-by: Anton Krivoborodov <anton.krivoborodov@bmw.de>
* Add release-note prompt with draft/final parameter
Signed-off-by: Anton Krivoborodov <anton.krivoborodov@bmw.de>
* Release note: address review findings (release selection by tag commit, one ref for all evidence, alias normalisation)
Signed-off-by: Anton Krivoborodov <anton.krivoborodov@bmw.de>
* Release note: run on the release candidate branch; drop the v0.10 note from this PR
Signed-off-by: Anton Krivoborodov <anton.krivoborodov@bmw.de>
* Release note: generate an architecture diagram with every skeleton run
The generator renders docs/s_core_v_1/releases/_assets/architecture_vX_Y.svg
from scratch (scripts/release_note/architecture_diagram.py) and embeds it in
the Overview: platform/infrastructure/tooling modules, the integrated software
modules with their components (Sphinx-Needs comp/mod from needs.json, --needs)
and the target images. Same inputs give a byte-identical SVG.
Skill and agent document the diagram as a generated part.
* Release note: take the diagram components from the checkout's needs.json
The generator builds //:needs_json_file with Bazel and reads bazel-bin/needs.json,
so the components match the module pins of the checked-out release branch instead
of the published main docs. A failing build stops the run; --needs only reproduces
a diagram from a kept file. Removes the unused diagram path without components.
* Release note: list commits without PR of the release branch as evidence
The evidence of this repository covers the range origin tag -> checked-out
release branch, but only squash-merged PRs ("(#N)") were listed, so commits
pushed directly to the release candidate branch were dropped. collect_changes.py
now lists them with their changed files (commits that only touch the release
notes are skipped). The skill classifies them like PRs and, on refresh, adds
items for new evidence while keeping the reviewed narrative.
---------
Signed-off-by: Anton Krivoborodov <anton.krivoborodov@bmw.de>
(cherry picked from commit 9f60b91)
…the release notes (#392) * Reduce Overall Status to per-module stacked progress charts The Overall Status page predated the Platform and Module Verification Reports and duplicated them: five large per-PA module tables, needpie process-status rows and rollout bars, all maintained by hand through a seven-file agent skill. Those reports are now the authoritative source for per-module status, so the page is cut down to the one thing they do not provide: progress across releases. What the page keeps is the four release-over-release charts (requirements, architecture, implementation, verification). Each bar is now stacked by module instead of a single aggregate block, so the composition of a release is visible at a glance, and a v0.10 (forecast) column shows the current state of the pinned modules. The section labels overall_status_pa2..pa5 are preserved because pi1/pi2/pi3.rst link to them. The data is no longer hand-maintained. scripts/overall_status/ collect_metrics.py walks the reference_integration release tags, reads each tag's known_good.json, resolves the module pins and counts requirements, architecture elements, lines of code and test definitions directly from the module sources into overall_status_data.json. generate_progress_charts.py renders the SVGs from that file and offers --check so CI can detect stale charts. Recounting every release from source changes previously published figures. Three reasons, all corrections: TRLC requirements were not parsed before (Communication and Config Management were badly undercounted), test counts were CI executions rather than test definitions, and lines of code were estimated from file sizes instead of counted. The page states that the numbers are source-derived and will not match CI dashboards. The skill collapses from seven files to one and the agent is rewritten around the two scripts. * Split verification chart into unit and integration tests The combined "tests per release" chart mixed two very different things: unit tests, which number in the thousands and are dominated by Baselibs and Communication, and component/feature integration tests, which number in the hundreds. The integration tests were invisible as a sliver at the top of the bar. collect_metrics.py now buckets a test definition by its path: anything under a directory named component, integration, integration_test(s), integration_testing or itf counts as an integration test, everything else as a unit test. Rendered as pa5_unit_test_progress.svg and pa5_integration_test_progress.svg; the combined pa5_verification_progress.svg is removed. The integration count also includes reference_integration's own feature tests under feature_integration_tests/ and platform_integration_tests/, attributed to the module under test via the path segment below them (RI_ALIASES). Without them Persistency would read as zero integration tests while actually having the most. reference_integration is measured from this checkout rather than a clone, and only its test count is taken - its lines of code stay out of the implementation chart, which counts module sources. Two presentation fixes: the slots within a bar are now ordered by size with the largest at the bottom, and MODULE_COLORS is documented as the single colour source shared by every chart, so a module is recognisable by the same colour throughout the page. * Move Overall Status to the releases as Release-wide Progress Overview The roadmap page overall_status.rst is replaced by docs/s_core_v_1/releases/progress_overview.rst, listed first in the releases toctree before the release notes. Data file, scripts (scripts/progress_overview), skill and agent (progress-overview) and the chart labels are renamed accordingly; the roadmap, PI pages, integration process docs and the v0.8 note link to it. collect_metrics.py orders the release tags by version (v0.10.0 after v0.9.0) and names the forecast column after the next release milestone of eclipse-score/score instead of a hard-coded label. Removes CSS for the old status tables that is no longer used. * Refresh the release-wide progress overview data (2026-10-29) Recollected all columns with collect_metrics.py on the branch merged with latest main and regenerated the charts. The release columns are unchanged; the v0.10 forecast column moves from 289 to 292 integration tests. (cherry picked from commit 75f2b3c)
- Fix patched after upstream deps update - export mw/log aou_requirements.rst from baselibs for score_logging consumption
…ifecycle 0.9.0 Persistency a804b85 (bumped in cb89c10) expects score_platform 0.7.4 and score_process_description 2.2.2 (feat_req version 2, feat_req__persistency__cfg_priority, wp__module_user_manual, gd_temp__rel_mod_user_manual). The previous pins were platform v0.7.2 and process_description v2.1.2, which caused 12 docs-check warnings. - score_process_description, score_platform and score_docs_as_code are now pinned to released registry versions (pin_version) instead of git commits. - score_platform 0.7.4 drops lifecycle feat_reqs that lifecycle 85da216 still linked (33 warnings), so score_lifecycle moves to v0.9.0 (2c3a919), which targets exactly platform 0.7.4 / process_description 2.2.2 / docs-as-code 8.6.0. - Lifecycle v0.9.0 no longer has its own glossary, so the platform patch removing the duplicated lifecycle glossary is obsolete (it would now hide the 'Monitoring of Processes' term). Removed. - patches/lifecycle/001 is already upstream in v0.9.0; removed. patches/lifecycle/002 rebased: score_itf is non-dev upstream, only the oci extension still needs un-deving. - Lifecycle's verification report moved to verification_report/module_verification_report (mod_ver_report); link updated in docs/verification_report/modules/index.rst. Local docs_shim build: the persistency and lifecycle warnings are gone; the remaining warnings are the logging v0.2.5 ones (31 mounts.path_escape, 2 absolute :doc: links). Also regenerates bazel_common/score_modules_target_sw.MODULE.bazel for the preceding persistency bump (3193244), which only touched known_good.json.
…chema
lifecycle v0.9.0 renamed all duration fields to integer milliseconds
(*_ms). The old keys fail schema validation in launch_manager_config:
"Additional properties are not allowed ('transition_timeout' was unexpected)".
delay_before_restart 0.5 -> delay_before_restart_ms 500
reporting_cycle 0.1 -> reporting_cycle_ms 100
transition_timeout 5 -> transition_timeout_ms 5000
transition_timeout 1.5 -> transition_timeout_ms 1500 (fallback run target)
evaluation_cycle 0.5 -> evaluation_cycle_ms 500 (defaults and global)
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.