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?
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development