ENH: Bump reusable workflow for wheel validation

[tbirdso]

Includes checks for wheel existence and naming scheme after wheel build routines.

[dzenanz]

Maybe this CMake warning is the culprit for breakage?

CMake Warning (dev) at /home/runner/work/_temp/1570127931/cmake-3.24.2-linux-x86_64/share/cmake-3.24/Modules/ExternalProject.cmake:3074 (message):
  The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
  not set.  The policy's OLD behavior will be used.  When using a URL
  download, the timestamps of extracted files should preferably be that of
  the time of extraction, otherwise code that depends on the extracted
  contents might not be rebuilt if the URL changes.  The OLD behavior
  preserves the timestamps from the archive instead, but this is usually not
  what you want.  Update your project to the NEW behavior or specify the
  DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
  robustness issue.
Call Stack (most recent call first):
  /home/runner/work/_temp/1570127931/cmake-3.24.2-linux-x86_64/share/cmake-3.24/Modules/ExternalProject.cmake:4170 (_ep_add_download_command)
  /home/runner/work/ITKSplitComponents/ITK/Utilities/ClangFormat/DownloadClangFormat.cmake:37 (ExternalProject_add)
  /home/runner/work/ITKSplitComponents/ITK/CMake/ITKModuleClangFormat.cmake:14 (include)
  /home/runner/work/ITKSplitComponents/ITK/CMake/ITKModuleMacros.cmake:9 (include)
  /home/runner/work/ITKSplitComponents/ITK/CMake/ITKModuleExternal.cmake:140 (include)
  CMakeLists.txt:9 (include)

[tbirdso]

Yes, though I am curious about where the issue is introduced. I am re-running checks in master for comparison: https://github.com/InsightSoftwareConsortium/ITKSplitComponents/actions/runs/3961122231

[dzenanz]

Was CMake version bumped? I think this warning starts with CMake 3.24.

[tbirdso]

You're right, the CMake version was bumped as part of warning fixes.

InsightSoftwareConsortium/ITKRemoteModuleBuildTestPackageAction@6e81bbd

It seems like this fix should be handled in ITK proper since it involves setting a CMake policy?

EDIT: Already logged in InsightSoftwareConsortium/ITK#3846

[tbirdso]

Re-running checks in master with CMake 3.24 has passed without warnings: https://github.com/InsightSoftwareConsortium/ITKSplitComponents/actions/runs/3961122231/jobs/6788272317

InsightSoftwareConsortium/ITK#3846 documents the issue but also includes references to where fixes where already introduced to ITK. Unclear where the error is suddenly coming from here.

[dzenanz]

ITKSplitComponents might need to set the policy, like this:
https://github.com/InsightSoftwareConsortium/ITKIOOMEZarrNGFF/blob/v0.1.0/CMakeLists.txt#L2-L4

[tbirdso]

Could this be added to ITKModuleExternal.cmake rather than requiring that each individual module set its own policy?

[tbirdso]

Error appears to have cleared on re-run for no reason? 😕

[dzenanz]

Could this be added to ITKModuleExternal.cmake rather than requiring that each individual module set its own policy?

Requiring a newer version of CMake will automatically set all previously introduced policies to NEW. Setting things in ITKModuleExternal.cmake would affect all remotes, even non-trivial ones. Maybe DownloadClangFormat.cmake could set that policy to NEW? Or push policy, set 135 to NEW, then pop?

[tbirdso]

Setting things in ITKModuleExternal.cmake would affect all remotes, even non-trivial ones.

Yes, that would be the goal. If that's not desirable then I'm fine with setting the policy here as needed. However, it seems like the issue may not be present in the latest run. Will do a third run to check again.

EDIT: MacOS builds have failed with warnings on the third, fourth, and fifth runs. No clue why the second passed. Will add a line to set the policy in CMakeLists.txt.