On Mar 30, 2020, at 5:56 PM, Vitaliy Lotorev lotorev@gmail.com wrote:

Hi,

I'm evaluating Zuul for project gating.

Currently my team is using Fast Forward Only submit strategy [1] with Gerrit Autosubmitter plugin [2]. Code-Review labels are copied if change is rebased trivially (no code change).

We use Fast Forward to keep Git history without merges and I wouldn't like to loose this feature while switching to Zuul.

I see that all projects gated with Zuul (e.g. Zuul itself, OpenStack) are using Merge If Necessary strategy. My confusion is: Gerrit has six different merge strategies and Zuul is responsible for merging all the code. Is there any combination of Gerrit/Zuul settings to preserve linear Git history?

I'm trying to understand what is wrong with Rebase If Necessary and Cherry Pick strategies. Why these strategies are not preferred for Zuul-gated projects? Will Zuul fetch random commits from A-B-C chain while using Cherry Pick or it will try to preserve the order.

OpenStack and Zuul don’t avoid those strategies because of any technical limitations on Zuul’s part - it’s actually because from a developer workflow perspective, having a commit rebase when it lands removes the developer’s ability to easily pull —ff-only in their repo (we tried it on some repos at one point and it spawned developer confusion) This may not be an issue for your devs - but we were supporting ~2.5k devs with a large variance in backgrounds and the “clean” history did not outweigh the dev confusion … at least for us.

All of that is to say - I don’t think it should be a fundamental issue for you to keep that merge strategy. Zuul and Gerrit already use different git implementations. Zuul will still prepare the correct state, and it will then (currently) just click the Submit button for you. Zuul will absolutely still preserve the logical order and correctness of your commit chains.

[1] https://gerrit-review.googlesource.com/Documentation/concept-changes.html#su... [2] https://gerrit.googlesource.com/plugins/autosubmitter/

Regards, Vitaliy _______________________________________________ Zuul-discuss mailing list Zuul-discuss@lists.zuul-ci.org http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss

On 31/03/2020 00:56, Vitaliy Lotorev wrote:

Hi,

I'm evaluating Zuul for project gating.

Currently my team is using Fast Forward Only submit strategy [1] with Gerrit Autosubmitter plugin [2]. Code-Review labels are copied if change is rebased trivially (no code change).

We use Fast Forward to keep Git history without merges and I wouldn't like to loose this feature while switching to Zuul.

I see that all projects gated with Zuul (e.g. Zuul itself, OpenStack) are using Merge If Necessary strategy. My confusion is: Gerrit has six different merge strategies and Zuul is responsible for merging all the code. Is there any combination of Gerrit/Zuul settings to preserve linear Git history?

I'm trying to understand what is wrong with Rebase If Necessary and Cherry Pick strategies. Why these strategies are not preferred for Zuul-gated projects? Will Zuul fetch random commits from A-B-C chain while using Cherry Pick or it will try to preserve the order?

[1] https://gerrit-review.googlesource.com/Documentation/concept-changes.html#su... [2] https://gerrit.googlesource.com/plugins/autosubmitter/

Regards, Vitaliy

Hello Vitaly,

Pick the following with a grain of salt, my experience is with Zuul 2.5 from 3 years ago. However a lot of the underlying principles are the same as Zuul v3 as far as Gerrit/merging are involved.  I have been maintaining repositories in Gerrit for years and with a fairly large audience (Wikimedia has a few hundred of Gerrit participants).

The fast forward only strategy looks seducing at first glance, it has a major drawback though: one can not submit a change in Gerrit if the branch has moved forward since the last patch got uploaded.  One thus has thus to rebase and submit again.  When a repository has sufficient traffic, developers race against each other and the race loser has to rebase.

Zuul does not support the fast forward only strategy when gating. If a change is not fast forward (it is based on a previous commit than the tip of the branch), Zuul still tries to do a merge commit (exactly: git merge -s resolve) which pass fine, it runs the test and then attempt to submit. But Gerrit eventually reject the change submit since it is not a fast forward. (reference: https://phabricator.wikimedia.org/T131008#3307337 ).  The strategy is not implemented.

Another example, if you have two changes A and B both being fast forward. They get both approved and Zuul will enqueue them. So A will be the branch + A, and B will be tested as branch + A + B. Assuming everything pass, Zuul will ask Gerrit to submit A, being fast forward it will be merged. Then ask for B to be submitted, but given A has just merge, B is no more fast forward! (some details with ascii art at https://phabricator.wikimedia.org/T111426#1605970 ).

What I found to work is to use the "Rebase if necessary strategy" and tick the "Allow content merge". An example of such history is https://github.com/wikimedia/integration-config/commits/master

The Allow Content Merge is convenient since it instructs jGit to handle trivial conflicts (which Zuul does since it uses C git).

When Allow Content Merge is false, Zuul still does a git merge -s resolve and thus does not reject the change. But in Gerrit, that sets the jGit flagSIMPLE_TWO_WAY_IN_CORE which rejects trivial conflicts. I have not found an equivalent in the C git version https://phabricator.wikimedia.org/T210442#4874113

There is some past thread about the merge strategies:

http://lists.zuul-ci.org/pipermail/zuul-discuss/2019-January/000688.html

The supported strategies are: merge, merge-resolve and cherry-pick. That is coded in zuul/merger/merger.py _mergeChange().  And I think the default is actually resolve which mismatch Gerrit defaulting to recursive.    Rebase if necessary although not supported, seems to work fine in my case.

--

Antoine "hashar" Musso

On Mon, 30 Mar 2020 at 23:58, Vitaliy Lotorev lotorev@gmail.com wrote:

Hi,

I'm evaluating Zuul for project gating.

Currently my team is using Fast Forward Only submit strategy [1] with Gerrit Autosubmitter plugin [2]. Code-Review labels are copied if change is rebased trivially (no code change).

We use Fast Forward to keep Git history without merges and I wouldn't like to loose this feature while switching to Zuul.

I see there are a few answers explaining how this isn't necessarily beneficial while working with Gerrit.

It might be a good idea to expand on why the preference for linear history? Might be easier to provide you with more info on behaviour around impacts to help you assess whether to implement the same workflow or whether the benefits of switching are more useful.

I've seen linear history be helpful for git bisect to investigate regressions that were introduced due to not being caught by tests in the past to avoid a scenario where there were other issues exposed on either side making it difficult to test, or the regression was buried somewhere in the middle of the set of commits merged in but there were other failures occurring in between those commits. Most of these problems though disappear with the model Gerrit applies in the first place with individual commits being reviewed and landed. I have used git bisect successfully to trace a regression not covered by tests in projects maintained in Gerrit using merge when necessary.

I first came across this with the wine project (winehq.org), and while I can see it being important in accepting stacks of patches, I think that unless you look to enable merge entire branch or merge set of commits (did that actually get merged to gerrit?) the general workflow of Gerrit tends to prevent the type of merging that would result in issues bisecting, and combining it with Zuul will mean all your commits pass tests anyway reducing the issue.

-- Darragh Bailey "Nothing is foolproof to a sufficiently talented fool"