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

Martin Jansa martin.jansa at gmail.com
Fri Nov 8 14:58:57 UTC 2019


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://).

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?

Regards,

On Fri, Nov 8, 2019 at 3:08 PM Adrian Ambrożewicz <
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
> http://lists.openembedded.org/mailman/listinfo/bitbake-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/bitbake-devel/attachments/20191108/399fc966/attachment.html>


More information about the bitbake-devel mailing list