-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: Linux internal build failure is silent #38
Comments
A similar issue was encountered in #52 where a package failed to install inside the docker image, resulting in a build failure that is not caught by the GitHub Actions runner and subsequently reported as a success. A minimum path to address this issue is to validate that the expected wheel / number of wheels is present in |
Adds step to validate that wheels are built successfully across platforms. Tailored to match granularity of build processes on each runner platform: - Each Linux job expects one wheel output and verifies Python version, toolset, target platform, target architecture; - Each Windows job expects one wheel output and verifies Python version, target platform; - Each macOS job expects one wheel output per Python version (currently 3.7-3.11) and verifies target platform and wheel count Addresses InsightSoftwareConsortium#38
Adds step to validate that wheels are built successfully across platforms. Tailored to match granularity of build processes on each runner platform: - Each Linux job expects one wheel output and verifies Python version, toolset, target platform, target architecture; - Each Windows job expects one wheel output and verifies Python version, target platform; - Each macOS job expects one wheel output per Python version (currently 3.7-3.11) and verifies target platform and wheel count `twine` Python package is used to validate wheel names match PyPI conventions. Addresses InsightSoftwareConsortium#38
Adds step to validate that wheels are built successfully across platforms. Tailored to match granularity of build processes on each runner platform: - Each Linux job expects one wheel output and verifies Python version, toolset, target platform, target architecture; - Each Windows job expects one wheel output and verifies Python version, target platform; - Each macOS job expects one wheel output per Python version (currently 3.7-3.11) and verifies target platform and wheel count `twine` Python package is used to validate wheel names match PyPI conventions. Addresses InsightSoftwareConsortium#38
Adds step to validate that wheels are built successfully across platforms. Tailored to match granularity of build processes on each runner platform: - Each Linux job expects one wheel output and verifies Python version, toolset, target platform, target architecture; - Each Windows job expects one wheel output and verifies Python version, target platform; - Each macOS job expects one wheel output per Python version (currently 3.7-3.11) and verifies target platform and wheel count `twine` Python package is used to validate wheel names match PyPI conventions. Addresses InsightSoftwareConsortium#38
Workaround introduced in #53 so that a job fails if expected wheel output is not produced. Closing for now with the potential to reopen if this fix proves insufficient for tracing errors. |
An issue was observed in the HASI repository where Linux wheel builds failed but jobs were marked as having completed successfully. MacOS and Windows wheels failed and were correctly marked as failed.
https://github.com/KitwareMedical/HASI/actions/runs/3750380351/jobs/6370024283
Steps to Reproduce
The HASI module depends on the ITKBoneEnhancement project. If ITKBoneEnhancement build outputs are not provided then HASI wheels are expected to fail.
Observed behavior
The HASI build begins inside the appropriate docker container and fails at the config stage. However, the failure does not seem to propagate from the container back to the host.
The text was updated successfully, but these errors were encountered: