[bitbake-devel] Patch idea - fetcher for gerrit patches

Tue Nov 12 14:14:01 UTC 2019

Hi,

it looks the same as any other recipe fetching from normal git repository
(not managed by gerrit), e.g.:

SRC_URI = "git://gerrit/projectA;name=A \
    git://gerrit/projectB;name=B \
"
SRCREV_FORMAT = "A_B"
SRCREV_A = "refs/changes/61/252561/44"
SRCREV_B = "refs/changes/62/252562/1"

In regular case SRCREV_A and SRCREV_B will be set to some git SHA, but to
build from some open reviews we just set the refs/changes/*/*/* in the
SRCREV variables (without changing SRC_URI except adding ;nobranch=1 which
is added through another variable - our exact case is a bit more
complicated, see:
https://github.com/webosose/meta-webosose/blob/master/meta-webos/conf/distro/include/webos-repositories.inc
 )
recipes then use e.g. WEBOSOSE_GIT_REPO_COMPLETE variable (there are more
variables like this in internal builds for different gerrit servers and
projects there), so the CI can just set WEBOS_GIT_BRANCH = ";nobranch=".

In regular builds this triggers QA error to prevent anyone merging change
like this by accident, because all our regular builds fetch from annotated
tags (the SRCREV is set to matching SHA and bbclass checks that the SHA is
matching with the corresponding submissions/N where N is part of the
component version), that's implemented as do_fetch[prefuncs] here:
https://github.com/webosose/meta-webosose/blob/master/meta-webos/classes/webos_enhanced_submissions.bbclass

Most our recipes use just one repository, so 99,9% cases is even simpler
than this.

Regards,

On Tue, Nov 12, 2019 at 3:01 PM Adrian Ambrożewicz <
adrian.ambrozewicz at linux.intel.com> wrote:

>
>
> W dniu 11/8/2019 o 15:58, Martin Jansa pisze:
> > Do we actually need separate fetcher for gerrit?
> >
> > We're using gerrit for everything @LGE and to fetch from open reviews
> > instead of merged commits I'm just setting the gerrit reference in
> > SRCREV (e.g. refs/changes/61/252561/44) and normal git fetcher does the
> > right think and fetches it correctly.
> >
> > Advantage of using the same fetcher is to easily switch between tag/git
> > ref/gerrit ref just by small SRC_URI modification instead of replacing
> > whole repository (starting from fetcher change from git:// to gerrit://).
> >
> That is very good suggestion and should work in simplest cases. How does
> SRC_URI and SRCREV look in your case?
>
> I see some limitations of that solution, but correct me if I'm wrong as
> my experience with bitbake is quite limited.. how about multiple
> patchse? How SRC_URI and SRCREV would look like then?
>
> > Adding optional parameter for git:// fetcher to make it easier to
> > specify which review to pull seems easier to use and less error prone
> > (as you probably never want to use e.g. review from glib gerrit project
> > in dbus recipe, so always including the project name and showing error
> > when the referenced review in change parameter doesn't point to the
> > right project is IMHO better then fetching something completely
> different).
> >
> > For topic parameter I don't understand how would you fetch the reviews
> > if there are more then one with the same topic? Would you fetch multiple
> > repositories in some automatically generated destdir directories? Or
> > fetch just the patches and apply them on top of some other SRC_URI entry?
> The latter. Our use case is contribution to many existing subrepos. We
> have a bunch of reviews to manage which combined on top of existing
> recipe builds our features. Gerrit fetcher in our case is aimed to
> address applying many patches of ongoing reviews until they are integrated.
> >
> > Regards,
> >
> > On Fri, Nov 8, 2019 at 3:08 PM Adrian Ambrożewicz
> > <adrian.ambrozewicz at linux.intel.com
> > <mailto:adrian.ambrozewicz at linux.intel.com>> wrote:
> >
> >     Hello,
> >
> >     As it is my first message here allow me to introduce myself. I'm
> Adrian
> >     Ambrożewicz and I work at Intel Technology Poland. I love flexibility
> >     and features of Bitbake and I would like to propose new feature which
> >     will solve our problem.
> >
> >     I would like to propose extension to already supported fetcher
> >     library -
> >     gerrit. Idea is to be able to apply gerrit patches by simply
> >     specifying:
> >     "SRC_URI += gerrit://[gerrit_server];change=[change_id]". Fetcher
> would
> >     then take care of downloading most recent patchset from given review.
> >     Further extensiosn of that fetcher could include ability to specify:
> >     - revision (get given revision instead of top)
> >     - topic (get all patches from given topic)
> >     - project (to be used in conjunction with 'topic' parameter)
> >     etc...
> >
> >     I've prepared minimal PoC implementation without any error handling.
> It
> >     works just fine and is basing on wget command. Gerrit REST API is
> used
> >     to obtain base64-encoded patch which is then decoded to file with
> name
> >     [change_id].patch . I'm very interested in polishing that and
> >     upstreaming it for everyone to use.
> >
> >     The question I have for you is the following: does this fetcher have
> a
> >     chance to be accepted upstream?
> >
> >     Regards,
> >     Adrian
> >     --
> >     _______________________________________________
> >     bitbake-devel mailing list
> >     bitbake-devel at lists.openembedded.org
> >     <mailto:bitbake-devel at lists.openembedded.org>
> >     http://lists.openembedded.org/mailman/listinfo/bitbake-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/bitbake-devel/attachments/20191112/c897ea07/attachment.html>