RTBC retests and merge requests

Another possibility would be to have DrupalCI attempt to merge the branch into 9.2.x (or equivalent) as the first step, but definitely need something like this.

I think the conflict in #3089525: Sort options should correspond to bundles selected for entity reference field settings is with #3168375: Convert calls to drupalPostForm(NULL, ...) to submitForm, not #3145005: [November 9, 2020] Remove uses of t() in drupalPostForm() calls. If I am right, then the situation is not quite so bad as described here: when #3089525 was made RTBC on 11-18, there was no conflict, since #3168375 was not committed until 11-23.

It does seem pointless to re-test a MR unless it is first merged with the target branch or converted to a patch.

Details:

Looking at https://git.drupalcode.org/project/drupal/-/merge_requests/34/diffs (the diffs for #3089525) I see

  	    // Third step: confirm.
+	    $page->findField('settings[handler_settings][target_bundles][' . $this->target_type . ']')->setValue($this->target_type);
+	    $assert_session->assertWaitOnAjaxRequest();
 	    $this->drupalPostForm(NULL, ['required' => '1'], 'Save settings');

This is the section of the code where Git showed me conflicts when I tried to merge. The last line (context) was updated in #3168375.

Gitlab can (check if possible and) rebase any MR to current HEAD with a single click. We could auto-trigger that rebase on yet-to-be-defined conditions. Or, at least, show "needs rebase" on d.o.

Gitlab can (check if possible and) rebase any MR to current HEAD with a single click. We could auto-trigger that rebase on yet-to-be-defined conditions. Or, at least, show "needs rebase" on d.o.

Excessive rebasing will be disruptive. For example, if I’m working on a commit for a merge request, I’ll have to figure out the upstream changes before I can get my work committed and pushed. Git does make this doable, I’d say it requires intermediate Git knowledge, and I’m sure will be a good learning experience for some. If I’m working the same hours as upstream commits and this happens multiple times, I expect it will be annoying.

Rebasing only needs to happen when resolving merge conflicts, or pulling in significant upstream changes for anyone developing on the branch.

This is of course not how this was intended to be implemented.

Is the MR mergeable with the issues selected branch

We have this check before any test, including RTBC retests, is sent to the dispatcher: https://git.drupalcode.org/project/project_issue_file_test/-/blob/abec3f..., which calls https://git.drupalcode.org/project/drupalorg/-/blob/7.x-3.x/drupalorg/in...

Has any non-conflicting change that has been committed caused the patch to MR's tests to fail

DrupalCI tests the result of the merge, as if it had been merged with the upstream commits: https://git.drupalcode.org/project/drupalci_testbot/-/blob/d685cd1f3ece0...

Our GitLab API integration was a bit shaky with passing the with_merge_status_recheck parameter to the GitLab API calls. I’ll start by double checking that functionality. If that wasn’t working properly, I could imagine it leaving the merge ref stale.

@alexpott how exactly were you applying the merge? For example, adding the remote and merging manually, using the merge interface at the bottom of the issue page, or by applying it as a patch?

A core MR test has been marked “Not currently mergeable.” as recently as a day ago: https://www.drupal.org/pift-ci-job/1909051

I found some inconsistent data for #3089525: Sort options should correspond to bundles selected for entity reference field settings tests, which would have been a symptom of https://git.drupalcode.org/project/project_issue_file_test/-/commit/abec... not having been deployed at the time. This created a rogue test that was failing, being retested, and would not have been visible on the issue page. I’ve cleaned up that data.

I’m reasonably comfortable saying that was the root cause, since there are 85 test runs that failed as “Not currently mergeable,” and the bad data was specifically for the issue you found. Do go ahead and re-open this if you spot anything different.

@drumm I was applying it as a patch. I've since learnt that if you add .patch to a MR url you get a patch with all the commits separated. If you add .diff you get something more akin to patches of old from the issue queue.

Thanks. I was questioning that this might have been in the narrow set of things Git can keep track of, like file renames, that might merge while patching fails.