On 16 Dec 2025, at 20:24, Even Rouault <[email protected]> wrote: > > Hi Roger, > > Thanks for working on that. > >> The other downside is that these systems are libtiff group runners; they >> are only accessible to members of projects within the libtiff GitLab group, >> so external or internal contributors who open merge requests from forked >> repositories won’t have the CI builds run successfully. Only branches >> pushed to the libtiff repository will run. > > That's indeed a major drawback to me. It will be hard to accept contributions > from casual contributors with such setup since they won't have push rights to > the libtiff repository. Is there somehow a way to have a mix of self-hosted > runners for thorough tests, while we keep the existing/past gitlab provided > runners for everyone?
Yes, we could just keep e.g. a single Linux build using a cloud runner to do a crude initial pass, and then do more thorough testing once it met that minimum bar. It might also be possible to exclude all of the other builds for building in a fork, so they won’t see all of the failures. This would also keep our CI minutes quota in check as well, since we wouldn’t be doing as much per merge request. I have previously done this for submissions where the user did not have appveyor set up; I would just fetch their branch and then push it up to the libtiff repo to check the builds all passed before approving it. This is essentially the same, but for more platforms. Kind regards, Roger _______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
