[Development] Suggestion to add labels when changing API

[Adam Treat]

On 12/08/2017 12:47 PM, Sergio Ahumada wrote:
> On 08.12.2017 16:50, Oswald Buddenhagen wrote:
>> On Fri, Dec 08, 2017 at 04:15:10PM +0100, Sergio Ahumada wrote:
>>> On 08.12.2017 15:42, Adam Treat wrote:
>>>> Relying upon qt5 submodule pins is the problem. The underlying 
>>>> issue is
>>>> atomicity of commits. Oswald is right.
>>>>
>>>> We need to have a way to provide atomic commits across modules at 
>>>> least
>>>> the CI should see these as atomic and integrate accordingly.
>>>>
>>>
>>> what about trying to enable gerrit topic's feature again for cross-repo
>>> changes?
>>>
>> from the ci perspective, that's both pointless (because the grouping can
>> be achieved temporally by just staging the changes at the same time) and
>> insufficient (because the system currently just won't do atomic
>> integrations).
>
> I meant provided the system is able to do atomic integrations, as Adam 
> suggested. But that would probably require quite a lot of more 
> computer power.

Why?

> actually, Adam's initial proposal sounds quite good to me
>
> > * Adopt something like Google's repo tool: 
> https://code.google.com/archive/p/git-repo/
> > * Stop using submodules and use a monolithic repo
>
> for both these proposals see https://bugreports.qt.io/browse/QTBUG-19580
>
> > * Implement atomic commit across submodules not in Git, but in the 
> gerrit/COIN layer so that COIN effectively locks integrations until 
> commits that span submodules are finished
>
> Use the topic feature to merge changes across repos once they are all 
> passed their CIs. Merge normal changes as usual after their CIs are 
> passed.
>
> Move the old dependencies from 
> sync.profile+http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules to the 
> demo-default.xml file proposed in QTBUG-19580 .. get the list of repos 
> to be cloned (or already built tgz) + needed sha1 to git-reset and 
> then git-cherry-pick the changes under test on top ..
>
> does that make any sense?

As another alternative I'm trying to figure out if Gitlab's CI system 
has a way to deal with this:

https://forum.gitlab.com/t/trigger-ci-build-if-any-dependent-git-repo-is-updated/9725

They do have ways to kick off integration jobs based on git triggers 
and/or other logic: https://docs.gitlab.com/ee/ci/yaml/#jobs

I think we could design atomic integrations across submodules with 
something like that.

In general, has anyone looked into Gitlab's CI system and 
compared/contrasted with COIN?