Release candidate 09 - #317
Draft
LittleHuba wants to merge 3 commits into
Draft
Conversation
Update known_good.json to a new, consistent, passing state across all
S-CORE modules, based on score_communication HEAD at the start of this
work, preferring published releases and falling back to a pinned
commit hash with atomic patches where no suitable recent release
exists.
Module changes:
- score_baselibs -> 0.2.12
- score_persistency -> 0.3.5 (rust_kvs moved from src/rust/rust_kvs to
score/kvs/rust_kvs; code_root_path/exclude_test_targets metadata
updated; obsolete patches 001-003 removed as fixed upstream)
- score_orchestrator -> 0.1.1
- score_kyron -> 0.1.3
- score_communication -> 0.4.0 (published release; existing patches
001-expose-comm-examples, 003-module-deps-visibility,
004-rules-build-error-not-dev-dependency apply cleanly and
unmodified against the 0.4.0 tag)
- score_lifecycle_health renamed to score_lifecycle -> 0.5.0 (kept in
its original position in known_good.json, directly after
score_kyron, to minimize diff in generated files)
- score_logging, score_time, score_config_management: hash-pinned to
new upstream HEADs, with patches regenerated/added:
- patches/logging/002-004 regenerated for context drift;
005-memory-shared-moved-to-communication.patch removed (merged
upstream)
- patches/time/001 regenerated; new
002-lifecycle-renamed-to-score_lifecycle.patch and
003-remove-obsolete-py_unittest_qnx_test.patch (score_time relied
on a py_unittest_qnx_test.bzl macro removed upstream from
score_baselibs)
- patches/config_management: new
002-lifecycle-renamed-to-score_lifecycle.patch
- tooling group bumped: score_crates -> 0.0.11, score_itf -> 0.5.0,
score_tooling -> 2.2.1, score_platform -> 0.7.1,
score_bazel_platforms -> 1.0.0, score_test_scenarios -> 0.4.1,
score_docs_as_code -> 8.0.1, score_process renamed to
score_process_description -> 2.1.2
Own-repository fixes required by the above bumps:
- bazel/toolchains/BUILD, bazel_common/score_llvm_libclang.MODULE.bazel:
adapt to score_tooling@2.2.1's new libclang_toolchain() signature
(cc_toolchain attribute instead of cxx_builtin_include/
extra_config_site) and expose the llvm_toolchain repo
- BUILD, showcases/simple_lifecycle/BUILD: fix @score_lifecycle_health
/ @score_process label references to the renamed modules
- feature_integration_tests/test_scenarios/rust/BUILD,
showcases/orchestration_persistency/BUILD: fix
@score_persistency//src/rust/rust_kvs ->
@score_persistency//score/kvs/rust_kvs
- .bazelrc: removed obsolete persistent_logging flag line
- MODULE.bazel.lock: updated for all new/changed module resolutions
Validated:
- bazel mod graph: passes
- bazel build --config=linux-x86_64 //images/linux_x86_64:image:
passes (full build)
- bazel build --config=linux-x86_64 //feature_integration_tests/itf:
passes (test target builds; only pre-existing deprecation warnings)
- Generated files confirmed self-consistent/idempotent with
known_good.json
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ore_baselibs score_communication's own MODULE.bazel already carries a single_version_override patch for score_baselibs (third_party/score_baselibs/restore_qnx8_poll_workaround.patch) that fixes AbortableBlockingReader::WaitForData on QNX8: inotify file descriptors often only report POLLRDNORM (not POLLIN) as readable, and without a finite poll timeout a resource-manager wakeup failure would block forever (Ticket-221150). However, bzlmod only honors single_version_override/git_override entries declared by the root module, so this patch was silently ignored when score_baselibs is resolved as a dependency of our own root module. Add the same patch as patches/baselibs/002-restore-qnx8-poll-workaround.patch and register it in known_good.json's score_baselibs bazel_patches, so inotify-based blocking reads work as expected on QNX8 in this integration as well. Verified the patch applies cleanly (git apply --check) against our currently pinned score_baselibs@0.2.12 checkout. Validated: - bazel mod graph: passes - bazel build --config=linux-x86_64 //images/linux_x86_64:image: passes (full build, 1484 actions) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…rage_report working
score_tooling@2.1.0 removed rust_coverage_report from its public API in
favor of a fundamentally different score_coverage_scope/
score_coverage_reporter design (aspect-based, driven by implementation
target deps rather than rust_test query strings). Our
rust_coverage/BUILD (one target per rust-capable module, generated
from known_good.json) still relies on the old API, so 2.2.1 broke
`bazel query //rust_coverage/...` outright ("package contains
errors").
rust_coverage_report is only present through score_tooling@2.0.2 (the
last tag before the 2.1.0 rewrite), so pin to that version instead.
Separately, score_tooling's own defs.bzl had already stopped exporting
use_format_targets before 2.0.0 (it moved to
third_party/format:macros.bzl); fix BUILD's load() accordingly. That
macro in turn requires @aspect_rules_lint, which score_tooling@2.0.2
declares as dev_dependency = True -- invisible to consumers under
bzlmod. Add patches/tooling/001-expose-aspect-rules-lint-non-dev.patch
(one-line: drop dev_dependency = True from the aspect_rules_lint
bazel_dep in MODULE.bazel) so the format targets keep working on
2.0.2, exactly as they do on 2.2.1.
Net effect: same working format.* targets as before, plus
rust_coverage/BUILD targets restored, on score_tooling@2.0.2.
A full migration to score_tooling's new coverage API (to move back to
a current release) is a separate, larger follow-up.
Validated:
- bazel mod graph: passes
- bazel query "//:all + //rust_coverage/...": passes, includes
//rust_coverage:rust_coverage_score_* targets and //:format.* targets
- bazel build --config=linux-x86_64 //images/linux_x86_64:image:
passes (full build, 1485 actions)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
LittleHuba
force-pushed
the
release_candidate_09
branch
from
August 28, 2026 10:54
e78b7d9 to
a9cecf5
Compare
4 tasks
Member
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
2 participants
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.
Changes required to get release candidate v0.9 flying.
I preferred existing releases if possible and went with recent hash and patches if latest release was not viable.
The modules that do not use a release should see the patches as the to-be-done work before a release.
The ones that already have a release linked should check the applied patches. If these patches are only fixing visibilities for the old testing approach in the ref_int, they are fine. If more is contained, they should consider creating a new release with these additional fixes.
In case of doubt, contact @PiotrKorkus for his judgement.