"Failed to check out": Internal dependencies not followed properly within a project (extra dependency)

The test is http://qa.drupal.org/pifr/test/238834

The failure is on uc_attribute_save() - it's not found.

It looks to me like you're doing a very wrong thing in the function where the failure happens. A "public static function" is not going to have access to the actual test instance since it's static. My bet is that you have uc_attribute() enabled in your install (the test-runner install). And of course it's not enabled on the test runner on the testbot.

Anyway, move the stuff out of static functions. That's my opinion anyway.

  public static function createAttribute($data = array(), $save = TRUE) {
    $attribute = $data + array(
      'name' => DrupalWebTestCase::randomName(8),
      'label' => DrupalWebTestCase::randomName(8),
      'description' => DrupalWebTestCase::randomName(8),
      'required' => mt_rand(0, 1) ? TRUE : FALSE,
      'display' => mt_rand(0, 3),
      'ordering' => mt_rand(-10, 10),
    );
    $attribute = (object) $attribute;
    if ($save) {
      uc_attribute_save($attribute);
    }
    return $attribute;
  }

Could you please disable all ubercart modules on your local and try to run the tests locally?

I did that on the testbot; here are the files and database. It does in fact not work as configured on the testbot.

Drupal checkout files: http://dl.dropbox.com/u/7350603/tmp/uc_dropdown_attributes.files.tgz
Drupal checkout database: http://dl.dropbox.com/u/7350603/tmp/uc_dropdown_attributes.sql.gz

Admin is admin/drupal - easier to use drush uli for it though.

Until you can get it to pass locally, this is not a testbot problem. I might take a look, but not sure I'll have time.

If you want to get this improved, you'll need to move it to drupal core in the simpletest component.

If the problem is that the wrong module is not available due to the testbot not loading a module, that's something we can fix on this end.

If you want to get this improved, you'll need to move it to drupal core in the simpletest component.

If the problem is that the wrong module is not available due to the testbot not loading a module, that's something we can fix on this end.

The project dependency module's job is to find out the chain of dependencies required to test a module.
Currently, it shows only

[rfay@www2 htdocs]$ drush pdsd uc_dropdown_attributes 7.x-1.x-dev
PHP Warning:  PHP Startup: apc.shm_size now uses M/G suffixes, please update your ini files in Unknown on line 0
Array
(
    [1414324] => Array
        (
            [uri] => ubercart
            [version] => 7.x-3.0-rc4
            [tag] => 7.x-3.0-rc4
        )

)

However, we know that uc 3.x requires far more than that. So I'm about to rebuild the dependencies for ubercart 3.x.... And after rebuild they're fine.

[rfay@www2 htdocs]$ drush pdsd ubercart 7.x-3.x-dev
PHP Warning:  PHP Startup: apc.shm_size now uses M/G suffixes, please update your ini files in Unknown on line 0
Array
(
    [1485738] => Array
        (
            [uri] => rules
            [version] => 7.x-2.1
            [tag] => 7.x-2.1
        )

    [1337360] => Array
        (
            [uri] => entity
            [version] => 7.x-1.0-rc1
            [tag] => 7.x-1.0-rc1
        )

    [1451068] => Array
        (
            [uri] => views
            [version] => 7.x-3.3
            [tag] => 7.x-3.3
        )

    [1507412] => Array
        (
            [uri] => ctools
            [version] => 7.x-1.0
            [tag] => 7.x-1.0
        )

    [1108406] => Array
        (
            [uri] => google_analytics
            [version] => 7.x-1.2
            [tag] => 7.x-1.2
        )

)

So this *looks* like a flaw in project_dependency. It's odd that although uc_dropdown_attributes has a dependency on uc_cart and uc_attribute, that dependency chain does not (seem to) get followed correctly.

It's possible that the fact that there's not a module called "ubercart" triggers a particular bug.

Moving this to Project Dependency. It will take some careful database study to sort it out. Thanks for your patience in explaining this. I wish I'd understood earlier that the dependencies required weren't being loaded on the box.

Manual analysis of the attributes goes like this:

uc_dropdown_attributes -> uc_attribute -> uc_product -> uc_store -> [nothing]
                                      -> uc_cart -> uc_order -> uc_store
                                                                           -> rules
                                                                           -> views
                                                        -> uc_product

And of course Drupal says on the module page:
Requires: Cart (disabled), Order (disabled), Store (disabled), Rules (missing), Views (missing), Product (disabled), Image (enabled), File (enabled), Field (enabled), Field SQL storage (enabled), Product attributes (disabled)

So somehow we're not finding our way to uc_cart or uc_order's dependencies.

It's my belief that the problem is going to come down to the limit on recursion levels, see the attached patch. But I'm out of time for tonight, and can't get this patch to solve the problem.

As you see in the above, rules is 5 levels deep, depending on how you count.

It's obvious we need a better patch, with a variable; if we've had to increase it this time, it may have to be increased again.

Note also, that although I don't think it matters, we're using Ubercart 3.0, since that's the recommended release, not Ubercart 7.x-3.x

Needs work for two reasons: The patch doesn't actually solve the problem, and it needs to use a variable_get()

The tests are completely abandoned, from a much earlier rendition of this module.

@trobey I'd be delighted to have you work on this, and would be pleased as punch to help you. You probably need to apply for a sandbox, http://drupal.org/node/1018084. If you do, let me know and I'll push the button. Project Dependency needs to know a pile of info about projects to work, so you need a database.

Very nice work.

So what's happening is that a dependency module (component) *within* the same release node package doesn't get followed, right?

I'm a little worried that this will skew the results for other modules and end up adding redundant internal references in. But I think there's a line of code that automatically removes those anyway. Just have to take a look and see.

Nicely done! Thanks!

Here's #22 rolled as a git patch rooted in the project. No changes. Testing today.

@trobey, probably what you should have done on your sandbox was to clone project_dependency into the sites/all/modules/project_dependency directory and then your patch would have been correct.

This looks great to me. Casual testing shows it resolves the OP, and I find no breakage with any other dependency generation.

Thanks!

Committed, http://drupalcode.org/project/project_dependency.git/commitdiff/8cc7a0b

Rolled into release: 6.x-1.0-beta2

Ready for d.o deployment.

Deployed on drupal.org.

Rebuilt the dependencies using jenkins and project_dependency_rebuild_project

The dependencies of uc_dropdown_attributes are now

drush pdsd uc_dropdown_attributes 7.x-1.x-dev
Array
(
    [1424926] => Array
        (
            [uri] => ubercart
            [version] => 7.x-3.0
            [tag] => 7.x-3.0
        )

    [1485738] => Array
        (
            [uri] => rules
            [version] => 7.x-2.1
            [tag] => 7.x-2.1
        )

    [1337360] => Array
        (
            [uri] => entity
            [version] => 7.x-1.0-rc1
            [tag] => 7.x-1.0-rc1
        )

    [1451068] => Array
        (
            [uri] => views
            [version] => 7.x-3.3
            [tag] => 7.x-3.3
        )

    [1507412] => Array
        (
            [uri] => ctools
            [version] => 7.x-1.0
            [tag] => 7.x-1.0
        )

)

Looks pretty good to me.

And it looks like success after a retest: http://qa.drupal.org/pifr/test/238834

Congrats and thanks, @trobey!

Of interest, possible bug: #1530452: Duplicate module checkout (Repository checkout: failed to checkout from [git://git.drupal.org/...]

Yeah, OG doesn't work right. It gets og listed as a dependency of itself. Odd that we don't have that problem with ubercart. Perhaps because Ubercart doesn't have a module named ubercart?

Moving to critical, as it appears this breaks many contrib modules. For Example, skinr is broken:

Skinr: http://qa.drupal.org/pifr/test/98689

Ubercart: http://qa.drupal.org/pifr/test/132134

I guess my testing must not have been adequate.

I reverted the deployment, so we're now back to 6.x-1.0-beta1 deployed on drupal.org, so this is no longer critical. We can work it at our leisure.

@trobey, I apologize for not getting this in. And now I'm traveling for the next week, so a very poor time to commit or deploy. But I'll at least try to look at it this week. Thanks so much for all your work on this.

#33 rerolled with proper root.

Looks good to me. Committed, http://drupalcode.org/project/project_dependency.git/commitdiff/7611b97

Now, we need a new release and deployment. Created 6.x-1.0-beta3

I'm going to be out all morning, so won't deploy now, but may try deploying this afternoon.

Thanks so much, @trobey.

Deployment is in progress.

Doesn't seem to have broken og, skinr, or uc_dropdown_attributes. YAY!
@trobey++

Sorry for the terrible lapse on this. I had a 3 week interruption in my life.

I'd appreciate it if you'd consider comaintaining this module, since you obviously already have a good grasp of it.