I recently learned that as hard as it is to believe, it appears that GitHub Actions provide free usage or runners for public repositories, and have exceedingly generous limits - 6 hours per job and 35 DAYS per workflow.
Maybe it is time to give it another consideration for building and packaging Slicer and extensions?
It would be great if someone could try that out. I haven’t tried for a couple of years, but as I recall the VMs had 2 pretty slow cores, so a linux build that could take as little as 30 minutes on a fast multicore machine took much longer.
Caching build directories for the superbuild prerequisites could definitely speed things up. I think that’s doable but I didn’t try very hard.
Thanks for the pointers. In the context of SlicerDMRI[1], we worked with @jhlegarreta to setup CI for the extension so that it builds Slicer and the associated extension.
Total time for building Slicer alone[2] using the ubuntu-22.04 worker is ~3.5hrs and I anticipate that the macOS and Windows build times would be longer (at least using the default worker made available for open-source project).
That said, with the availability of dedicated resources to both support the implementation of the infrastructure as well as more performant workers, we should be able to further leverage GitHub Actions infrastructure.
In the meantime, here are some issues we need to address:
Lastly, to fully adapt the GitHub Actions infrastructure, we would also need runner for M1 to be available. See GitHub Actions: Apple Silicon (M1) powered macOS runners (Public Beta) · Issue #528 · github/roadmap · GitHub