DR-008 Option 4: two-stage test-execution workflow (PR 2 of 2) - #280
DR-008 Option 4: two-stage test-execution workflow (PR 2 of 2)#280Subramanian-K812 wants to merge 15 commits into
Conversation
c9462ea to
fd3df76
Compare
d293277 to
b6df34d
Compare
e51b340 to
640dfee
Compare
|
The created documentation from the pull request is available at: docu-html |
04a7a73 to
e816620
Compare
PiotrKorkus
left a comment
There was a problem hiding this comment.
as the workflow has been completely reworked please create a private fork and execute it there, so we can see the proof of working in CI
pull_request_target wont allow to execute it here
|
Ran the reworked workflow end-to-end on a private fork: |
b22c037 to
a992474
Compare
587dcbb to
35d83cd
Compare
There was a problem hiding this comment.
review focus ./scripts/known_good, excluding tests.
Transitive dependency are now correctly pinned 👍 .
Patches from reference integration are locally applied but patching in Stage 2 uses single_version_override and git_override without patches, which leads to missing patches for module dependencies, which were present in Stage 1.
|
@Subramanian-K812 Thanks a lot for the quick rework 👍 . Unfortunately I am not at work till 09.09., once I am back I can continue the re-review. |
MaximilianSoerenPollak
left a comment
There was a problem hiding this comment.
Some questions from my side.
But overall I think it does what was asked according to the DR.
| --stage1-result "${{ needs.stage1_integration.result }}" \ | ||
| --stage2-result "${{ needs.stage2_module_validation.result }}" \ | ||
| --stage2-dir "_stage2_reports/" \ | ||
| >> "$GITHUB_STEP_SUMMARY" |
There was a problem hiding this comment.
Is there an output lenght limit for the step summary?
If there is, will this hit it or is there no risk of that?
There was a problem hiding this comment.
Checked against GitHub's actual limit (1 MiB per step, upload fails with an annotation if exceeded) — a full 8-module report from the real script is ~4.3 KB, so this should not reach the cap.
| still points at the old @score_baselibs labels, so redirect them and declare the | ||
| score_communication dependency they now require. | ||
|
|
||
| Source labels only; the module's .bazelrc has the same stale labels but ref_int no longer patches it. |
There was a problem hiding this comment.
But if it's stale labels should they not be removed?
There was a problem hiding this comment.
We could, but that would require patching the module’s .bazelrc, which has already been ruled out for this PR.
| # scripts/ on sys.path, so "from known_good...." resolves under 'bazel run' as it does for | ||
| # "python3 scripts/...". Propagates to every consumer of this library. | ||
| imports = [".."], |
There was a problem hiding this comment.
Are you sure this does not break anything else?
Importing .. can have unexpected consequences in consumers of this py_library.
There was a problem hiding this comment.
Yes agreed — better to scope or drop imports than leave it shared.
|
|
||
| def repo_slug(repo_url: str) -> str: | ||
| """Derive the 'owner/name' slug actions/checkout expects from a git URL.""" | ||
| match = re.search(r"[:/]([^/:]+/[^/:]+?)(?:\.git)?/?$", repo_url or "") |
There was a problem hiding this comment.
Very sure this regex does more and less than what it is suppose to do (as all regex).
But I guess it's okay for now?
There was a problem hiding this comment.
This to be improved — switching to urllib.parse for the path url in known_good.json.
| try: | ||
| from known_good.models.known_good import load_known_good | ||
| from known_good.resolved_dependencies import repo_root, workspace_path | ||
| except ImportError: | ||
| if str(_HERE) not in sys.path: | ||
| sys.path.insert(0, str(_HERE)) | ||
| from models.known_good import load_known_good # noqa: E402 | ||
| from resolved_dependencies import repo_root, workspace_path # noqa: E402 |
There was a problem hiding this comment.
Why is this needed again?
There was a problem hiding this comment.
Agreed — same as noted below, the current try/except isn’t ideal and will be improved in a follow‑up.
| if module.repo in repo_commit_dict: | ||
| commit = repo_commit_dict[module.repo] | ||
|
|
||
| # Generate patches lines if bazel_patches exist | ||
| patches_lines = "" | ||
| if module.bazel_patches: | ||
| patches_lines = " patches = [\n" | ||
| for patch in module.bazel_patches: | ||
| patches_lines += f' "{patch}",\n' | ||
| patches_lines += " ],\n" | ||
| patch_strip_line = " patch_strip = 1,\n" if patches_lines else "" | ||
|
|
||
| if module.version: | ||
| # If version is provided, use bazel_dep with single_version_override | ||
| block = ( | ||
| f'bazel_dep(name = "{module.name}")\n' | ||
| "single_version_override(\n" | ||
| f' module_name = "{module.name}",\n' | ||
| f"{patch_strip_line}" | ||
| f"{patches_lines}" | ||
| f' version = "{module.version}",\n' | ||
| ")\n" | ||
| ) | ||
| else: | ||
| if not module.repo or not commit: | ||
| logging.warning( | ||
| "Skipping module %s with missing repo or commit: repo=%s, commit=%s", | ||
| module.name, | ||
| module.repo, | ||
| commit, | ||
| ) | ||
| continue | ||
|
|
||
| # Validate commit hash format (7-40 hex characters) | ||
| if not re.match(r"^[a-fA-F0-9]{7,40}$", commit): | ||
| logging.warning( | ||
| "Skipping module %s with invalid commit hash: %s", | ||
| module.name, | ||
| commit, | ||
| ) | ||
| continue | ||
|
|
||
| # If no version, use bazel_dep with git_override | ||
| # Only include patch_strip if there are patches to apply | ||
| block = ( | ||
| f'bazel_dep(name = "{module.name}")\n' | ||
| "git_override(\n" | ||
| f' module_name = "{module.name}",\n' | ||
| f' commit = "{commit}",\n' | ||
| f"{patch_strip_line}" | ||
| f"{patches_lines}" | ||
| f' remote = "{module.repo}",\n' | ||
| ")\n" | ||
| ) | ||
| blocks.append(block) |
There was a problem hiding this comment.
This whole logic not needed anymore, or moved somewhere else?
There was a problem hiding this comment.
Moved, not removed — now imported from resolved_dependencies.generate_override_directive so Stage 1 and Stage 2 can't emit different git_override syntax.
| _HERE = Path(__file__).resolve().parent | ||
| try: | ||
| from known_good.module_patches import patch_relpath | ||
| from known_good.resolved_dependencies import ( | ||
| INJECTED_PATCHES_PKG, | ||
| _collect_resolved_versions, | ||
| injected_override_names, | ||
| workspace_path, | ||
| ) | ||
| except ImportError: | ||
| if str(_HERE) not in sys.path: | ||
| sys.path.insert(0, str(_HERE)) | ||
| from module_patches import patch_relpath # noqa: E402 | ||
| from resolved_dependencies import ( # noqa: E402 | ||
| INJECTED_PATCHES_PKG, | ||
| _collect_resolved_versions, | ||
| injected_override_names, | ||
| workspace_path, | ||
| ) |
There was a problem hiding this comment.
I'm sure there is a better way than to this try / except.
What are you trying to achieve with this again?
There was a problem hiding this comment.
Agreed — the current try/except isn’t ideal; it’s a leftover from the same pattern used in files that are still invoked directly, which don’t have py_binary targets, so those workflows call the .py files directly instead of through bazel run.
| @@ -0,0 +1,187 @@ | |||
| #!/usr/bin/env python3 | |||
There was a problem hiding this comment.
If this file runs in CI, be careful that we already had the issue (in docs-as-code) that we ran into the upper limit of a pipe buffer in the CI output (64kb) due to folding it with long prints.
Just an FYI
There was a problem hiding this comment.
Thanks for the heads-up, this file's output isn't piped into anything in CI — it runs as a plain bazel run step straight to the job log, so the pipe-buffer deadlock docs-as-code hit shouldn't be an issue here.
PiotrKorkus
left a comment
There was a problem hiding this comment.
- nested bazel invokes in
ferrocene_report.shcoming from the toolchain do not carry--noworkspace_rcwhich makes rust coverage fail - huge differences in number of executed tests. e.g. communication has 6500 test cases under
//score/...but here we run only 3800. Why do we have differences when we should execute from the score of tested repo just with common config and deps? - how about appending single line with import of common bazelrc to the one in tested module and using the config from it? Would that work or?
8b5251f to
891e471
Compare
DR-008 Option 4: two-stage test-execution workflow (PR 2 of 2)
Closes #264. This is the second of two PRs. It is stacked on PR 1
(
Subramanian-K812_resolve_override_mechanism, "resolved-dependency resolve + overridemechanism") — please review/merge that one first. Until PR 1 merges, this PR's base branch
is the PR-1 branch, so the diff shown here is only the test-execution delta.
What this PR does
Rewires the quality workflow to the DR-008 Option 4 flow, using the resolve + override
mechanism added in PR 1:
exports the resolved dependency set as the
stage1-resolved-depsartifact(
resolved_versions.json).known_good.json(target_sw) — never hardcoded.known_goodcommit, overridesits
MODULE.bazelwith the Stage-1 resolved set (PR 1's mechanism), and runs themodule's own unit tests + coverage as the Bazel root (
//...).release-tag test-report ZIP).
Files
Workflow & runners
.github/workflows/test_and_docs.yml— two-stage restructure (+ parallel docs build)scripts/quality_runners.py— module-context mode (--module-dir/--resolved-deps); callsResolvedDependencies.overwritescripts/aggregate_quality_report.py— new, consolidated reportscripts/known_good/list_modules.py— new, dynamic Stage-2 matrix fromknown_good.jsonscripts/integration_test.py— derive build targets fromknown_good.json(dropbuild_config.json)Resolved pins + their config ripple (kept together so the tree is self-consistent)
known_good.json— pin bumps (baselibs, lifecycle) + per-modulebazel_config+ lifecyclecode_root_path/extra_test_configbazel_common/score_basic_bazel.MODULE.bazel— flatbuffers bumpbazel_common/score_modules_target_sw.MODULE.bazel— regenerated (baselibs, lifecycle)MODULE.bazel.lock— updated lockrust_coverage/BUILD— lifecycle query//src/...→//score/...(layout moved by the bump)showcases/simple_lifecycle/BUILD— lifecycle bin path//src/...→//score/launch_manager.bazelrc— coverage atomic-gcov /-no-coverage; eb-aarch64 outline-atomics link fixKnown Stage 2 integration findings (surfaced, not fixed here)
The workflow surfaces two module-owned integration failures caused by the
baselibs bump (
score_loggingCheckSizeValidstaleuint8_tassumption;score_persistencyto_stringonstd::string_view).