Re: CPE Git Forge Decision

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux