COMP: Update CI best practices and Python 3.10+#93
COMP: Update CI best practices and Python 3.10+#93dzenanz merged 3 commits intoKitwareMedical:mainfrom
Conversation
|
Preferably squash first and last commit. |
b895500 to
764e96f
Compare
|
Done in 764e96f — collapsed the first commit ( The PR now has three logical commits: update actions/checkout to v5, update minimum Python to 3.10+, and update ITKRemoteModuleBuildTestPackageAction directly from v5.4.4 to v5.4.6 (no intermediate Force-pushed with |
The `Test Python HASI` workflow has been queued-but-never-started on PR KitwareMedical#93 because every element of its toolchain has bit-rotted out from under it: * Runner images `ubuntu-18.04`, `windows-2019`, and `macos-10.15` have all been retired by GitHub Actions, so the jobs sit in `queued` indefinitely and never get scheduled onto a runner. On PR KitwareMedical#93 they are the only non-green checks. * Python 3.7 (pinned by this workflow) is end-of-life (June 2023) and is not installable on modern runner images via `actions/setup-python@v5`. * The pinned test dependencies -- `itk==5.2.0.post2` (2021), `itk-shape==0.2.1`, `dwd==1.0.1` -- are incompatible with the `itk` 5.4.x API that the rest of HASI now targets via `ITKRemoteModuleBuildTestPackageAction@v5.4.6`. * The IPFS-hosted test data workflow relies on `ibnesayeed/setup-ipfs@master` plus an `ipfs pin add` of a CID that is no longer reliably pinned on the public swarm. The last successful run of this workflow predates 2025-03: every run since has been `cancelled` or `failure`. Rather than mask that with `continue-on-error: true` (which hides real regressions behind a green badge) or delete the file (which throws away the scaffold and makes it harder to revive the Python tests later), switch the trigger to `workflow_dispatch` only so the file survives as a skeleton for a future modernization pass. Also bump the matrix entries from the retired images to `ubuntu-latest` / `windows-latest` / `macos-latest` and Python from 3.7 to 3.10 so that whoever re-enables the workflow has one less thing to rewrite. The `src/hasi/test_*.py` pytest files themselves are untouched and still runnable locally. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The `Test Python HASI` workflow has been queued-but-never-started on PR KitwareMedical#93 because every element of its toolchain has bit-rotted out from under it: * Runner images `ubuntu-18.04`, `windows-2019`, and `macos-10.15` have all been retired by GitHub Actions, so the jobs sit in `queued` indefinitely and never get scheduled onto a runner. On PR KitwareMedical#93 they are the only non-green checks. * Python 3.7 (pinned by this workflow) is end-of-life (June 2023) and is not installable on modern runner images via `actions/setup-python@v5`. * The pinned test dependencies -- `itk==5.2.0.post2` (2021), `itk-shape==0.2.1`, `dwd==1.0.1` -- are incompatible with the `itk` 5.4.x API that the rest of HASI now targets via `ITKRemoteModuleBuildTestPackageAction@v5.4.6`. * The IPFS-hosted test data workflow relies on `ibnesayeed/setup-ipfs@master` plus an `ipfs pin add` of a CID that is no longer reliably pinned on the public swarm. The last successful run of this workflow predates 2025-03: every run since has been `cancelled` or `failure`. Rather than mask that with `continue-on-error: true` (which hides real regressions behind a green badge) or delete the file (which throws away the scaffold and makes it harder to revive the Python tests later), switch the trigger to `workflow_dispatch` only so the file survives as a skeleton for a future modernization pass. Also bump the matrix entries from the retired images to the house canonical `[ubuntu-24.04, windows-2022, macos-14]` and Python from 3.7 to 3.10 so that whoever re-enables the workflow has one less thing to rewrite. The `src/hasi/test_*.py` pytest files themselves are untouched and still runnable locally. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ffc8e3c to
60e531f
Compare
Two orthogonal modernizations to .github/workflows/test-python-hasi.yml folded into one commit because they both leave the workflow's author-time state in a consistent shape: 1. Bump `actions/checkout@v4` -> `actions/checkout@v5` so the workflow scaffolding matches the rest of HASI's CI on modern runners. 2. Disable the workflow on push/pull_request events and carry forward the matrix / Python / include-block updates needed for a future revival. The `Test Python HASI` workflow has been queued-but-never-started on PR KitwareMedical#93 because every element of its toolchain has bit-rotted out from under it: * Runner images `ubuntu-18.04`, `windows-2019`, and `macos-10.15` have all been retired by GitHub Actions, so the jobs sit in `queued` indefinitely and never get scheduled onto a runner. On PR KitwareMedical#93 they were the only non-green checks. * Python 3.7 (pinned by this workflow) is end-of-life (June 2023) and is not installable on modern runner images via `actions/setup-python@v5`. * The pinned test dependencies -- `itk==5.2.0.post2` (2021), `itk-shape==0.2.1`, `dwd==1.0.1` -- are incompatible with the `itk` 5.4.x API that the rest of HASI now targets via `ITKRemoteModuleBuildTestPackageAction@v5.4.6`. * The IPFS-hosted test data workflow relies on `ibnesayeed/setup-ipfs@master` plus an `ipfs pin add` of a CID that is no longer reliably pinned on the public swarm. The last successful run of this workflow predates 2025-03: every run since has been `cancelled` or `failure`. Rather than mask that with `continue-on-error: true` (which hides real regressions behind a green badge) or delete the file (which throws away the scaffold and makes it harder to revive the Python tests later), switch the trigger to `workflow_dispatch` only so the file survives as a skeleton for a future modernization pass. Also bump the matrix entries from the retired images to the house canonical `[ubuntu-24.04, windows-2022, macos-14]` and Python from 3.7 to 3.10 so that whoever re-enables the workflow has one less thing to rewrite. The `src/hasi/test_*.py` pytest files themselves are untouched and still runnable locally. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
60e531f to
46c767c
Compare
dzenanz
left a comment
There was a problem hiding this comment.
LGTM, but preferably someone else should review this too.
Update clang-format linter, actions/checkout@v5, Python 3.10+, ITKRemoteModuleBuildTestPackageAction@v5.4.6.