I remember that there have been some deadlocks caused every time devs did a force merge, and allegedly there is still a type of slowness which happens after a force merge, but I'm not clear on the details. It would be great to discuss here (if this is the right place), or link to a Phabricator task which discusses the issue.
Topic on Talk:Continuous integration/Zuul
Filled as https://phabricator.wikimedia.org/T225955 so we document it and eventually send patches to fix the issues if that is possible :]
Thanks, the explanation in that task helps me understand what causes the issue. I think I also understand that it's a bit of a race condition and depends on repo configuration, which is why it sometimes crashes Jenkins/Gearman and sometimes does not.
What do you think about these potential improvements to the situation?
- When Zuul tries to merge a change but the change is already (force) merged:
- If the resulting merged file tree is identical to what was already merged, then the merge step will complete successfully, as if we had performed the merge. Post-merge steps will still run.
- If the resulting merge is different than what was already merged, Jenkins posts a V-1 to the change and reports, "Unexpected merge detected /o\"
- When Zuul reports V-1 on a change but the change is already (force) merged:
- Maybe Jenkins then posts a V-2, or just another V-1, with the message "Unexpected merge of failing change, please take action to correct!"