Skip to content
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

Closed
tbirdso opened this issue Dec 22, 2022 · 2 comments
Closed

BUG: Linux internal build failure is silent #38

tbirdso opened this issue Dec 22, 2022 · 2 comments

Comments

@tbirdso
Copy link
Collaborator

tbirdso commented Dec 22, 2022

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.

  1. Fetch ITK build artifacts (without ITKBoneEnhancement)
  2. Try building HASI with ITKPythonPackage build scripts

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.

@tbirdso
Copy link
Collaborator Author

tbirdso commented Jan 13, 2023

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 dist/ after the build process completes and before artifact upload is attempted.

tbirdso added a commit to tbirdso/ITKRemoteModuleBuildTestPackageAction that referenced this issue Jan 16, 2023
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
tbirdso added a commit to tbirdso/ITKRemoteModuleBuildTestPackageAction that referenced this issue Jan 18, 2023
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
tbirdso added a commit to tbirdso/ITKRemoteModuleBuildTestPackageAction that referenced this issue Jan 18, 2023
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
tbirdso added a commit to tbirdso/ITKRemoteModuleBuildTestPackageAction that referenced this issue Jan 19, 2023
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
@tbirdso
Copy link
Collaborator Author

tbirdso commented Jan 28, 2023

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.

@tbirdso tbirdso closed this as completed Jan 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant