| Re: [oniro-dev] Use GitLab merge trains to optimize development workflow |
|
Hi all, The only downside of this approach is losing fast-forward merges but on the other hand, this seems to be planned in GitLab development so hopefully, it will be just a flick of a button when it lands: https://gitlab.com/groups/gitlab-org/-/epics/4911 Nevertheless, given the current pain of merging things I completely support this trade-off. This issue is more apparent in repositories where there is a greater level of concurrency – and probably the `oniro`
repository is the worst affected. Here, merge requests can easily take 2-4 days to just catch a merge chance. This slow CI feedback and the constant need to keep an eye on your merge requests create an unreasonable development overhead. Andrei From: oniro-dev [mailto:oniro-dev-bounces@xxxxxxxxxxx]
On Behalf Of Esben Haabendal Hi With this email, I would like to come with a proposal to use GitLab merge trains to optimize the development workflow when working on Oniro repository. Please read it through, and reply back with what you think. Hate it? Love it? Let's do this now!? Concerns? Anything that is unclear? Problem: Currently, developers contributing to eclipse/oniro-core/oniro repository are going through a rough time. In order to get something merged, the MR needs to be rebased to the current (kirkstone) branch HEAD. So when
multiple MR are trying to get merged at the same time, the MR that gets merged first wins. All the rest will have to rebase to the new HEAD, and run a completely new pipeline. When enough MRs are pending at the same time, it effectively becomes a time consuming Whack-a-mole game. Not only does this cost developer time, as developer needs to keep an eye on the MR progress, and do rebasing as needed to hopefully win out at get merged first at some point in time. But CI will end up being loaded
more than needed, as many MR ends up being run through its complete pipeline several times before it is merged. And finally, calendar time is impacted heavily, as the time needed to get a MR merged is unpredictable and much larger than what should be expected. Solution: Enable GitLab merge trains. See https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html This allows multiple pending MRs to be processed by CI in proper order, so that if all MR pipelines succeed, only one pipeline per MR will be run, and no developer interaction will be needed. So it saves calendar time, CI resources and developer time. As a consequence, the current implementation of GitLab merge trains requires use of merge commits, so the oniro repository will switch from fast-forward merges (linear history) to to using merge commits. |