According to my understanding we don't have any pressure at the moment to move the build machines themselves, "just" to find a solution for the cache eviction. We could also use some cheap S3 storage as a drop in replacement with the risk that this is not as fast as the current github cache, but this would be easier to do than to deploy our own runners.
... however, if we want to move to self hosted runners, a few thoughts: - We will need multiple architectures (I assume at least windows x64, linux x64, macos arm64) - We will need to install the required dependencies (build tools etc) and manage the system images. I guess on linux that's straightforward with docker, not sure how this should be done on other platforms (some VMs?) - We will need to do the required system administration and maintenance For the vcpkg builds, I would appreciate having our own runners, as it would make the operating system and build tool updates more predictable. Right now, this happens every few weeks when github rolls out new runner images. Every time this happens all dependencies are rebuilt which takes a few hours (more than 6 hours which is the github runner limit). Such full rebuilds could be reduced. If we provision our own runners we should probably also get stronger ones than the free ones from github. Cheers Matthias On Tue, Oct 14, 2025 at 3:39 PM Greg Troxel via QGIS-Developer < [email protected]> wrote: > (psc dropped because it will bounce) > > As part of this, I think it would be good to consider how things might > be different after a move from github to either codeberg or self-hosted > forgejo. I don't mean to really design that, just a background thought > of "if we (qgis.org) buy this hardware, and we later move, will we wish > we had done something different, or will we just need more, and this > will all be entirely usable, so it's fine". I suspect it really is > fine. > > 16 GB sounds like low RAM for a CI machine for qgis. I would want to > make sure it's expandable to at least 64G, and would start a bit higher. > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
