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

[Adrian Ambrożewicz]

W dniu 11/11/2019 o 16:24, Khem Raj pisze:
> On Mon, 2019-11-11 at 07:58 +0000, Mikko.Rapeli at bmw.de wrote:
>> Hi,
>>
>> Interesting idea.
>>
>> We use gerrit but don't neeed to expose gerrit details to bitbake
>> fetcher.
>>
>> Instead, we use gerrit changes to fetch meta layer changes using a
>> separate checkout
>> script. It handles gerrit topics, e.g. same topic name is used to
>> bundle changes
>> from multiple meta layer git trees. This enables large transitions
>> and updates as single
>> topic.
We've tried approach with separate script. It's just ankward to use 
separate checkout script for fetching and patching sources, when in fact 
bitbake provides those utilities, just isn't compatible directly with 
that SCM yet.

Idea is to have separate layer combining WIP/reviewed commits submitted 
to different repositories as our 'baseline'. Gerrit fetcher would take 
care of that.

> 
> There is a similar setup we have for CI using gerrit, but once you
> start playing with fetchers, bitbake is not happy and the build
> consistency is jeopardized as well, e.g. new QA checks etc, come in way
> in other words you have to maintain this additional CI fetch method and
> it grows cruft. So I would think if we were to do some additional work
> in fetchers to achieve this, that would be long term sustainable, and
> perhaps useful for other gerrit users or other SCMs
> 
>>
>> In our case it's a grave bug to use SRC_URIs in bitbake recipes
>> without referring
>> to proper branch and commit id. There have been cases where a commit-
>> id from an open
>> gerrit review got integrated which is bad, bad. I can only imagine
>> that testing
>> could be easier if bitbake recipes were to support gerrit directly,
>> e.g. to trigger
>> a bitbake test build for an open gerrit review change. But there are
>> other ways
>> to script that without exposing gerrit details to bitbake.
I agree, it would be easier and much more logical to integrate patches 
in my layers just by specifying ongoing reviews. Why forcing user to 
write his own external scripts to do that when proper patches might be 
fetched and applied natively. We've tried that and failed miserably.

>>
>> So I'm not sure if this gerrit fetcher is easier. At least I would
>> like to disable it,
>> or add a custom QA check which forbids its use in release build
>> recipes.
In 'my' use case gerrit fetcher is aimed directly to ease development 
for large features scattered among many repos. Opt-in for enabling that 
and big warning in build log could be reasonable solution.

>>
>> Cheers,
>>
>> -Mikko
>