Automated tests are failing because an exception is being thrown and not caught.

See: http://qa.drupal.org/pifr/test/381618 at the moment, it says:

MigrateException: No migration found with machine name DateExample in MigrationBase::getInstance() (line 444 of /var/lib/drupaltestbot/sites/default/files/checkout/sites/default/modules/migrate/includes/base.inc).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Alan D.’s picture

PatchRanger’s picture

Status: Active » Needs review
FileSize
1.66 KB
3.59 KB

An improved version of patch from #1832544: Class registration for Migrate 2.5 or later: it completely eliminates the problem with current Simpletest-test, while that patch does not. See below:

Interdiff is attached.

PatchRanger’s picture

I've decided to re-roll the patch, giving credits in commit message to the creator of original patch.

mikeryan’s picture

Priority: Critical » Normal
Status: Needs review » Needs work

Better to register the example migration via hook_migrate_api().

PatchRanger’s picture

Priority: Normal » Critical
Status: Needs work » Needs review

Better to register the example migration via hook_migrate_api().

It is registered (as you could see) - but it doesn't work for fixing this issue. Please take a look at the links I provided: they prove that these changes to your original patch are really important and necessary.
Changing back to 'needs review'.
Changing back to 'critical' also, because it is a show-stopper for entire Date issue queue, isn't it?

mikeryan’s picture

Priority: Critical » Normal
Status: Needs review » Needs work

It's up to the Date maintainers, ultimately, but I don't believe a falsely-failing test is "critical".

If fixing the tests is considered an essential part of the original issue, then that should be done in the original issue, with this issue closed as a duplicate.

What I'm saying is that hook_migrate_api() is a preferable means of registering static migrations like this, registerMigration would be used when you're dynamically creating migrations (as from a UI).

PatchRanger’s picture

Priority: Normal » Critical
Status: Needs work » Needs review

... but I don't believe a falsely-failing test is "critical".

I doubt it is surprise to you that failing branch makes all submitted patches 'postponed' until it gets fixed. So the entire development process of Date module depends on this issue - that's why it is critical.

If fixing the tests is considered an essential part of the original issue, then that should be done in the original issue, with this issue closed as a duplicate.

My goal was to fix Simpletest-tests, because my recent patch is stuck (see #1365516: Start date is not excluded when an exception for it is set for reference). Your patch became a part of final solution. The result has been posted here - and your issue was closed as a duplicate, because it has only part of the solution. It is reasonable, isn't it?

What I'm saying is that hook_migrate_api() is a preferable means of registering static migrations like this, registerMigration would be used when you're dynamically creating migrations (as from a UI).

You're definitely, completely, ultimately right. I know it too. But it doesn't work without this hook: it should, but it doesn't - let's think why it happens. Any suggestions?

tim.plunkett’s picture

Assigned: Unassigned » tim.plunkett

I'll try this out tonight. I realize it might not be the 100% best way, but we need the branch tests to pass.

PatchRanger’s picture

@tim.plunkett Any update please? It is very important, because it makes testbot stuck.

mikeryan’s picture

This patch has been incorporated into the consolidated patch at #2034231: [META] Integrated patch for migration changes.

cafuego’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

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