Problem/Motivation

Make sure the functional tests in migrate_drupal_ui work without tracker installed and that the migration tests in tracker still work when tracker is removed from core.

Steps to reproduce

Proposed resolution

Add @todo where needed to remove tracker references in the removal issue
Copy the d7 fixture to tracker for the tracker tests and update cspell.json to ignore it
Create a version of NoMultilingualReviewPageTest to confirm that Tracker will be upgrade when enabled on the destination
Do not create an Upgrade7Test in tracker because there are no entities to count.

Remaining tasks

Patch
Review
Commit

User interface changes

API changes

Data model changes

Release notes snippet

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quietone created an issue. See original summary.

quietone’s picture

Issue summary: View changes
Status: Active » Needs review
FileSize
1.74 MB

Let's try this.

Status: Needs review » Needs work

The last submitted patch, 2: 3267314-2.patch, failed testing. View results

quietone’s picture

Copied the wrong file. Start again for NoMultilingualReviewPageTest in tracker.

quietone’s picture

I think the test is failing because a directory, which is empty, is not created. This should fix that and I've trimmed down the ReviewPage test to the bare minimum.

quietone’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 5: 3267314-5.patch, failed testing. View results

quietone’s picture

Status: Needs work » Needs review
FileSize
9.45 KB

Adding a review only patch that removes the test fixture from the patch in #5.

The failing tests are random javascript test fails, so setting this to NR.

quietone’s picture

Rereoll

Status: Needs review » Needs work

The last submitted patch, 9: 3267314-9.patch, failed testing. View results

quietone’s picture

Failure was 1) Drupal\Tests\layout_builder\FunctionalJavascript\ContextualLinksTest::testContextualLinks

This just reduces the size of the tracker fixture by removing things like translations and lots of fields. The fixture still works on a d7 site.

Status: Needs review » Needs work

The last submitted patch, 11: 3267314-10.patch, failed testing. View results

quietone’s picture

Status: Needs work » Needs review

The failure on 10 was Drupal\Tests\quickedit\FunctionalJavascript\QuickEditFileTest::testRemove

quietone’s picture

FileSize
694 bytes
930.01 KB

Adding an @todo. No need to run tests again for a comment.

danflanagan8’s picture

Status: Needs review » Needs work

@quietone, I think I found a couple things that need an update.

1. After applying the patch in #14 I still see tracker referenced in MigrateDrupal6AuditIdsTest and MigrateDrupal7AuditIdsTest. I think we probably need to add the standard @todo for those.

2. I think that we can remove the cspell line from Drupal\Tests\tracker\Functional\Migrate\ReviewPageTest. That appears to be a copy/paste relic.

3. Is MigrateTrackerSettingsTest completely new test coverage? That's not a problem exactly, but it's driving me nuts that I can't figure out where that came from.

Looking good! I'm going to set back to NW.

quietone’s picture

Status: Needs work » Needs review
FileSize
5.45 KB
934.9 KB

@danflanagan8, thanks.

#1. I was more careful in my checking for 'tracker' this time and have added more @todo, including the files mentioned.
#2. Done
#3. It is not a new test. It is testing d7_tracker_settings, #2353777: Migrate Tracker module variables in D7.

The tests of the ReviewPage in migrate_drupal_ui are still testing with Tracker enabled and just have @todos to remove tracker later. Ideally, Tracker would not be installed in these tests but I am not convinced the extra work to do that is needed. The ReviewPage relies on the state files, and the combination of state files and the possible combinations is well tested.

danflanagan8’s picture

Thanks for the updates, @quietone, especially the note on d7_tracker_settings. My question must have sounded crazy now that I see that file is not new, just very slightly modified. D'oh!

At this point I am noticing an inconsistency between this issue and the issue to remove aggregator. In that issue, aggregator got uninstalled in the ReviewPage tests and it got moved from the getAvailablePaths to getMissingPaths. And there is no @todo to remove "Aggregator" from getMissingPaths. I recently defended this in #3264120-17: Remove aggregator module and our dependency on Laminas Feed:

There are several mentions of "Aggregator" in migrate_drupal_ui tests, but this is only in the context of MigrateUpgradeTestBase::getMissingPaths. That is correct and does not need any attention.

Your latest patch though adds @todos to remove tracker from getAvailablePaths but there's nothing about adding them to getMissingPaths. And the RDF patch actually adds @todos to remove RDF from getMissingPaths.
(RDF issue: #3267513: Handle migration tests for removing RDF)

So now I'm not sure which of the approaches is correct. I had assumed aggregator would be the model, but maybe not. Can you clarify for me?

quietone’s picture

I had assumed aggregator would be the model

Unfortunately that is not true. How each module behaves depends on its status in the standard profile, the source database, and if there are related migrations. We discovered with aggregator that the block migration will migrate all blocks, including aggregator ones. So we left those blocks in the source database since the migration needs to handle that case properly, we should test it. That make aggregator a special case.

Patch needed a reroll.

Status: Needs review » Needs work

The last submitted patch, 18: 3267314-18.patch, failed testing. View results

quietone’s picture

Status: Needs work » Needs review

Unrelated fail, Drupal\Tests\media_library\FunctionalJavascript\WidgetOEmbedTest::testWidgetOEmbedAdvancedUi.

Spokje’s picture

Status: Needs review » Reviewed & tested by the community

LGTM

Spokje’s picture

Priority: Normal » Major
Issue tags: +blocker

Since this is blocking #3261452: [11.x] Remove tracker module from core, which has priority major, also bumping this one to major.

  • catch committed 12762b4 on 10.0.x
    Issue #3267314 by quietone, danflanagan8: Handle migration tests for...
  • catch committed 6166cd0 on 9.5.x
    Issue #3267314 by quietone, danflanagan8: Handle migration tests for...
catch’s picture

Version: 10.0.x-dev » 9.5.x-dev
Status: Reviewed & tested by the community » Fixed

Committed/pushed to 10.0.x and cherry-picked to 9.5.x, thanks!

Spokje’s picture

Priority: Major » Critical
Status: Fixed » Needs work

I have _no_ clue how this happened, but by the look of https://www.drupal.org/pift-ci-job/2408230 the commit to 10.0.x broke HEAD.

Reopening and marking as Critical.

  • catch committed add472c on 10.0.x
    Revert "Issue #3267314 by quietone, danflanagan8: Handle migration tests...
catch’s picture

Status: Needs work » Needs review

I've reverted this from 10.0.x, left it in 9.5.x until we know whether we need to redo the patch here or it's an unlucky interaction with another patch.

catch’s picture

Sent the patch for a fresh run against 10.0.x

Spokje’s picture

"Fun" stuff, the patch now fails similar in the way HEAD failed when the patch was applied, weirdly on it's previous runs, the last one being literary one hour before the commit on both 9.5.x and 10.0.x (https://www.drupal.org/pift-ci-job/2408203) it returned all green.

10.0.x HEAD comes back with the same 70 failures after the patch was reverted.

Something with the letters W, T and F springs to mind...

I can only conclude that this patch isn't the root cause of the HEAD failure.

  • catch committed 8f72e9c on 10.0.x
    Issue #3267314 by quietone, danflanagan8: Handle migration tests for...
catch’s picture

Since this doesn't look like the culprit, I've reverted the revert. However I also can't see an obvious candidate for the culprit either.

Spokje’s picture

Status: Needs review » Fixed

I think this needs to go back to fixed since the revert was reverted and both 9.5.x and 10.0.x contain this code.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.