[Development] Suggestion to add labels when changing API
Adam Treat
adam.treat at qt.io
Fri Dec 8 20:52:53 CET 2017
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?
More information about the Development
mailing list