[Top][All Lists]

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

Re: [RFC] Using gitlab for upstream qemu repo?

From: Daniel P . Berrangé
Subject: Re: [RFC] Using gitlab for upstream qemu repo?
Date: Fri, 23 Oct 2020 09:51:31 +0100
User-agent: Mutt/1.14.6 (2020-07-11)

On Thu, Oct 22, 2020 at 12:24:28PM -0500, Eric Blake wrote:
> On 10/22/20 11:47 AM, Paolo Bonzini wrote:
> > Hi all,
> > 
> > now that Gitlab is the primary CI infrastructure for QEMU, and that all
> > QEMU git repositories (including mirrors) are available on Gitlab, I
> > would like to propose that committers use Gitlab when merging commits to
> > QEMU repositories.
> > 
> > Nothing would change for developers, who would still have access to all
> > three sets of repositories (git.qemu.org, gitlab.com and github.com).
> > Committers however would need to have an account on the
> > https://gitlab.com/qemu-project organization with access to the
> > repositories they care about.  They would also lose write access to
> > /srv/git on qemu.org.
> For clarification, I'm assuming the set of committers is rather small,
> and not the same as the set of subsystem maintainers who send pull
> requests for a committer to then merge in.  Does this proposal mean that
> pull requests would have to switch to gitlab merge requests, or would
> there be a transition period where submaintainers still send pull
> requests via whichever means desired (mail or gitlab merge request), but
> the eventual committer repackages that as a gitlab merge request before
> it is upstream?
> > 
> > Of course this is just starting a discussion, so I'm not even proposing
> > a date for the switch.
> I'm hoping that as part of the consideration that we make sure that
> command line tooling can still drive everything; there is a difference
> between requiring a web page to initiate a merge request, vs. proper
> command line tooling one to leave the web page as an optional part of
> the workflow for only those who want it.

Since Paolo's only suggesting move of the git server here, it should not
impact anything that is done today. Any CLI tools that talk plain git
to git.qemu.org will work unchanged against git.qemu.org or gitlab.com.

To answer your question though, GitLab has an extensive REST API that
lets you drive almost everything that is exposed in their Web UI. There
is my own Bichon tool (https://gitlab.com/bichon-project/bichon) that
uses the API to provide an interactive terminal based review UI, while
the Lab tool (https://github.com/zaquestion/lab) provides a text based
non-interactive CLI for use from shell/scripts again using the REST

Not commonly known is that GitLab also has support for Git push options,
which let you create merge requests using a plain "git push":


eg if you have a remote called "gitlab", you can open a MR from the CLI

 $ git push -o merge_request.create \
            -o merge_request.title="Do awesome thing" \
            gitlab my-branch

This is something that I could see being easily wired up into a
"git-publish" like tool for example.

|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

reply via email to

[Prev in Thread] Current Thread [Next in Thread]