Evaluate transition to self-hosted GitHub runners & GitHub workflows for extension builds #79
Description
As part of maintaining the nightly builds for Slicer extensions, we are evaluating the transition from using cron jobs and Windows Task Scheduler to scheduled GitHub Workflows running on self-hosted runners.
To enable this, we would need to register a GitHub runner on the following systems:
- metroplex
- computron
- bluestreak
Note
We are currently evaluating the feasibility and trade-off of this approach. The rationale and expected benefits are outlined below.
Current limitations of cron/Task Scheduler
Our current setup relies on .bat and .sh scripts launched via Task Scheduler (Windows) or cron (Linux & macOS). This has several drawbacks:
- Errors at the script level are not logged or reported in a central place.
- Restarting or re-triggering jobs requires manually SSH-ing into the machine.
- Build progress is only reported once all extensions are built, making it difficult to track in real time.
Benefits of GitHub Workflows
By moving to scheduled workflows maintained in Slicer/DashboardScripts:
- All GitHub Actions used in the GitHub workflow will be reviewed and pinned to specific versions.
- Runners will be restricted to this repository through a dedicated runner group.
- Infrastructure will be simplified and easier to maintain.
- Build progress, logs, and errors will be visible directly in GitHub, improving transparency and debuggability.
Build process context
To help understand, the nightly build process is currently driven by a top-level CTest script that:
(1) Clones or updates the Slicer/ExtensionsIndex repository (a set of JSON files with extension repositories and revisions)
(2) Generates a CMake project with one ExternalProject per extension (capturing inter-dependencies)
(3) Builds the top-level project in parallel.
(4) Submits results to CDash, both for the top-level project and for each individual extension build.
For example:
cc: @sjh26