Adding bootstrap --test-mode #865
Conversation
LalatenduMohanty
changed the title
LalatenduMohanty
force-pushed
the
take3_bootstrap_testmode
branch
2 times, most recently
from
197a919 to
539fe7c
Compare
LalatenduMohanty
force-pushed
the
take3_bootstrap_testmode
branch
3 times, most recently
from
4b69da3 to
6b2e255
Compare
src/fromager/bootstrapper.py
Outdated
|
|
||
| # Return a version to allow processing to continue | ||
| # Use cached version if available, otherwise return a null version | ||
| return resolved_version or Version("0.0.0") |
There was a problem hiding this comment.
Does anything actually use the version that is returned by bootstrap()? I thought when we looked at the code we found that nothing did.
--test-mode enables resilient bootstrap processing that continues building packages even when individual builds fail, instead of stopping at the first error. When a package fails to build from source, it attempts to download a pre-built wheel as a fallback, and if both fail, records the failure and continues processing remaining packages. At the end, it generates JSON reports (test-mode-failures.json and test-mode-summary.json) containing all failure details for automation and CI/CD integration. Closes python-wheel-build#713 Signed-off-by: Lalatendu Mohanty <[email protected]>
LalatenduMohanty
force-pushed
the
take3_bootstrap_testmode
branch
3 times, most recently
from
a45a357 to
905415a
Compare
Fixed gaps in error catching and test-mode specific logic moved the Bootstrapper class for better separation of concerns. Signed-off-by: Lalatendu Mohanty <[email protected]>
LalatenduMohanty
force-pushed
the
take3_bootstrap_testmode
branch
from
905415a to
72ba5d2
Compare
| # Track failed builds in test mode | ||
| self.failed_builds: list[BuildFailure] = [] | ||
|
|
||
| def resolve_and_add_top_level( |
There was a problem hiding this comment.
This is good. I hadn't even thought of the need for wrapping this step.
| if not cached: | ||
| # Version resolution failed during recursive processing. | ||
| # Record this before re-raising since we cannot continue | ||
| # without a version. (Top-level resolution errors are handled |
There was a problem hiding this comment.
What would happen if we record the error and then return None in that case? I think nothing actually looks at the return value of bootstrap(). We could even change the function to not return anything.
| req, | ||
| resolved_version, | ||
| prebuilt_error, | ||
| category=FailureCategory.PREBUILT_DOWNLOAD, |
There was a problem hiding this comment.
I think we only need separate error handling in order to capture this category. I see you created the BootstrapPhaseError class to wrap some errors. We could use that to move the logic for calling _record_failure() into bootstrap() in one place by catching that exception type separately from Exception.
|
|
||
| self.write_test_mode_report(work_dir) | ||
|
|
||
| if self.failed_builds: |
There was a problem hiding this comment.
This method would have less indented code if this condition was reversed and returned 0 here.
2 participants
--test-mode enables resilient bootstrap processing that continues building packages even when individual builds fail, instead of stopping at the first error.
When a package fails to build from source, it attempts to download a pre-built wheel as a fallback, and if both fail, records the failure and continues processing remaining packages.
At the end, it generates JSON reports (test-mode-failures.json and test-mode-summary.json) containing all failure details. The files go to work_dir/ like other outputs.
Closes #713