Mechanism that adds custom drupalci.yml configurations does not detect configs in new branches.

Excerpt from SELECT slid, elid, successful, errors, from_unixtime(start), from_unixtime(end), end - start delta, substring(message, 1, 100) FROM versioncontrol_sync_log WHERE repo_id = 2 ORDER BY elid DESC LIMIT 140;

| 1416910 | 1704345 |          0 |      1 | 2019-03-07 22:01:29.111100 | 2019-03-07 22:01:29.135200 |  0.024100065231323242 | Locked repository: The repository drupal at /var/git/repositories/project/drupal.git is locked, a sy |
| 1416907 | 1704342 |       NULL |   NULL | 2019-03-07 21:55:27.686100 | NULL                       |                  NULL | NULL                                                                                                 |
| 1416707 | 1704142 |          1 |   NULL | 2019-03-07 09:32:35.877600 | 2019-03-07 09:32:36.570500 |    0.6928999423980713 | NULL                                                                                                 |

The earliest one, at the bottom, is a normal example of commit processing.

The middle one is probably branching 8.7.x. All the NULLs lead me to think something took a long time to process and the DB connection idled away.

(GitLab syncing has a protection against this, https://cgit.drupalcode.org/versioncontrol_gitlab/tree/includes/Versionc...)

The lock that took out on the repository, in the versioncontrol_repositories.locked column, remained locked and subsequent pushes weren’t pushed. This also blocks further processing, like code arrival hooks, like this.

I cleared the lock, but there hasn’t been a core commit since then to set off the pachinko machine.

I’m back-filling some of this processing with:

$repository = versioncontrol_repository_load(2);
$event = $repository->loadEvent(1704354);

$sync_options = $repository->getSynchronizerOptions();
if ($repository->syncEvent($event, $sync_options)) {
  // Fire the notification hook on success: new code is here, parsed and
  // ready to go!
  // @todo Passing the repository to the hook is redundant, the event already
  // have it, remove it.
  module_invoke_all('versioncontrol_code_arrival', $repository, $event);
}

The first one I did got the commit on https://www.drupal.org/node/3060/commits and a commit comment on #3033912: Hide the module that imports Umami's content. The log mentioned project_dependency running. A DrupalCI run did not get kicked off.

The missing events have all been artisanally processed. And I went ahead and added https://www.drupal.org/pift-ci-job/1222518 since 8.8.x only had one test run.

Project packaging was triggered by this work, the dev releases should be caught up now.

I got hit by this, apparently, on #3099984-5: Composer require failure since Drupal 8.8.0, so it also affects contrib testing.

artisanally processed

😄

This is critical issue because every time we create a new core branch we have to re-learn this - see #3122328: TestSiteApplicationTest::testInstallWithFileWithNoClass() fails on 9.1.x and #3211992: TestSiteApplicationTest::testInstallWithNonExistingFile() fails when another test creates database tables during the test run

As part of both #3253134: Clean up/remove project_composer_project_release_create_package() & #3248795: Reduce Drupal.org coupling to GitLab on git.drupalcode.org, we can resolve this too.

Is there a follow-up for this in core/drupalci.yml yet:

# This is the DrupalCI testbot build file for Drupal core.
# Learn to make one for your own drupal.org project:
# https://www.drupal.org/drupalorg/docs/drupal-ci/customizing-drupalci-testing
# Until https://www.drupal.org/project/project_issue_file_test/issues/3038596 is
# fixed this file needs to change when a new core branch is made. Latest branch
# is 9.4.x.

I don’t think there was, I opened #3270886: Remove outdated note in drupalci.yml