Details
-
Suggestion
-
Resolution: Unresolved
-
P2: Important
-
None
-
None
-
None
Description
Currently, if direct submits requires triggering rebuild of build branch
<gerrit ssh command> staging-rebuild --project <project> --branch <branch>
otherwise, this will create separate merge commits
commit 36d7d295386466dcac92aaf7992c07f2f08ab8f3 (HEAD -> master, origin/master, origin/HEAD)
Merge: fb1a3e7c 0569ebc1
Author: Dimitrios Apostolou <jimis@qt.io>
Date: Tue Apr 21 10:11:50 2020 +0000
Merge "Fix links to VM monitoring dashboards"
commit 0569ebc111d997f017294584c0301d171cbda87d
Author: Dimitrios Apostolou <jimis@qt.io>
Date: Tue Apr 21 10:11:50 2020 +0000
Fix links to VM monitoring dashboards
Change-Id: Ia04c1859303754c5514f0d7b4ada4d1b126061d8
Reviewed-by: Aapo Keskimolo <aapo.keskimolo@qt.io>
The merges are redundant and the auxiliary merges provide no additional value since the build branch refs as stored in gerrit, eg.
git ls-remote fcfc1ec0605bbcfc41b1137a18f19ce695411042 refs/builds/qtci/vsphere/1552227232
If direct submits would go though regular build flow build->staging->merge then the merge commits would not create extra merge commits (i.e. cherrypicks). This means that direct submits would need to be blocked if there are any integrating changes to avoid race conditions and regular staging build failing during being merged. If there are ongoing integrations then these can be cancelled so its not a big issue.