On Fri, Apr 3, 2020 at 9:11 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > I also hope there will be an opportunity for discussion (with input > from the community) of whether those requirements can be fulfilled in > some way *other* than using a non-free Gitlab product. To take the > 'merge train' example - as Neal and I have mentioned, Pagure now in > fact *does* have some impressive capabilities in this area, thanks to > the Pagure<->Zuul integration that the Software Factory folks have been > working on, and presented at Devconf. I am personally using this for > multiple projects, and blogged about it here: > > https://www.happyassassin.net/2020/02/12/using-zuul-ci-with-pagure-io/ > As far as I understand the "merge train" feature from Gitlab, it seems to be similar to Zuul's "speculative merging" feature, except that Zuul is multi-repository aware by design, and thus Zuul is able to gate changes in their order of approval across a logical (user defined) set of repositories. When a project's code is spread across multiple repositories then Zuul's approach is invaluable. A striking example of a project spanning multiple repositories is of course Fedora where all packages are in their own dist-git repository. Another feature offered by Zuul that might be relevant in the dist-git context is the ability to have Zuul test PRs that require other (still unmerged) PRs. This allows creating CI jobs capable of handling build and runtime dependencies of RPMs. > an obvious avenue to explore here would be "can we work with Software > Factory folks to do a similar integration between Gitlab Core and > Zuul"? On the face of it, that would offer a way to achieve these > capabilities in a fully F/OSS way. > As for Gitlab integration, a driver is available for Zuul, but it is not as feature complete compared to the other drivers like the Pagure one. It might take some time to cover the missing bits; it might also be necessary to submit feature requests to gitlab's APIs themselves. I have been involved in writing those drivers and I fear it might not be as "easy" as it was for the Pagure driver. I might be wrong, but I don't expect any support from the gitlab side, for an obvious reason: offering "free" integration with Zuul would effectively kill their effort on monetizing "merge train", a similar in-house feature. On the other hand, I'd like to point out that working with Pagure maintainers to discuss missing features (mainly API endpoints) was really productive. Pagure folks are welcoming and provide guidance so it was easy for me to implement most of the missing pieces in the code to integrate with Zuul. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
