Hi,

I have a project with a submodule that adds dependencies for testing. The dependencies were committed a few days ago and are not getting updated when the -dev release is regenerated.

Here's the test result page: http://qa.drupal.org/pifr/test/310608

the patch only removes the dependencies key on the info array to force the tests to run but the dependencies are not detected.

boombatower checked the dependencies in the project in d.o but they were not updated since around January 2012.

This might be related with the fact that the project has no named releases, but supposedly according to #698932: "test_dependencies" for dependencies / integration tests they should be there.

Also, sun is having the same problem here: http://qa.drupal.org/pifr/test/305443 (should checkout the classloader module dependency, but does not)

Comments

boombatower’s picture

The log messages that I thought were January were bogus, I figured that out. Those were error messages so that would have been a good thing. :) Either way it seems the dependency parsing is being triggered properly.

Also had drumm run a query to check to see what was in database and it did not contain the proper dependencies so it is not a transportation issue to qa.d.o. The parsing or storage on d.o side is not completely correctly.

sun’s picture

I already reviewed the responsible code, but the main .info parsing looks straightforward to me:
http://drupalcode.org/project/project_dependency.git/blob/refs/heads/6.x...

Therefore, I rather suspect some hiccup in the project release checkout + parsing code, which is the part that is way more complex... :-/

lucascaro’s picture

Yeah, I thought it could be due to not having a named release in the project but @sun's project has named releases, so it must be something else. Do you guys think this is a problem with the project module?

rfay’s picture

Status: Active » Closed (works as designed)

@lucascaro, dependencies are *only* generated on creation of a release, including rerolling a dev release. The configuration project has only context, features, ctools, and views as dependencies.

To change this, you'll have to commit a change to the info file.

It would have helped me ever so much if you'd given the specifics of what module dependencies you were concerned with, what versions, etc. I have only an hour in a laundromat... Will be back and look at this again later in the month if you have followup. Testbot FAQs are at http://drupal.org/project/testbot.


$ drush pdsd configuration 7.x-1.x-dev
Array
(
    [1590284] => Array
        (
            [uri] => context
            [version] => 7.x-3.0-beta3
            [tag] => 7.x-3.0-beta3
        )

    [1719782] => Array
        (
            [uri] => ctools
            [version] => 7.x-1.1
            [tag] => 7.x-1.1
        )

    [1700490] => Array
        (
            [uri] => features
            [version] => 7.x-1.0
            [tag] => 7.x-1.0
        )

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

)
sun’s picture

Status: Closed (works as designed) » Active

The basics of "how it is supposed to work" are known already ;)

Some more research happened on this already, unfortunately without any clues.

As clarified in the OP, @lucascaro's case happens to share the identical symptoms like mine:

  1. Existing project. Existing tests.
  2. New major branch. New module dependencies. New dependencies declared in .info file.
  3. Testbot does not pick up the new dependencies in terms of project dependencies and checked out code for test runs.
  4. Project dependencies are not updated, regardless of commits, files being touched, or development snapshots being re-created.

I'm not too familiar with @lucascaro's case, but I can precisely explain mine:

  1. Inline 7.x-1.x exists for a long time already.
  2. New Inline 7.x-2.x major branch was created. Requiring classloader module in its .info file.
  3. The test's review log precisely states that the only repositories being checked out are Drupal core and Inline.
  4. A development snapshot for 7.x-2.x exists for many weeks already. It is constantly updated.
  5. I even committed nonsense to classloader module in order to trigger a dev snapshot rebuild for that.
  6. Project dependencies for Inline module have been rebuilt via Jenkins (or whatever backend/maintenance environment) by @boombatower and independently from that by someone else in #drupal-infrastructure (can't remember).
  7. End result is still the same: The new project dependency is not picked up. It is not contained in project_dependency's records in the first place; i.e., a manual query for inline module dependencies yielded no results.
lucascaro’s picture

@rfay well, the (optional) dependencies for configuration, as defined in the configuration_test.info file are surprisingly, ctools, views, context and features. so either somebody fixed it or it just took a week to re generate the dependencies :D

This was not the case on friday august 10th (which is the date of the last tested patch prior to the dependencies being fixed).

could @rfay's "drush pdsd configuration 7.x-1.x-dev" command have triggered a refresh for the dependencies? was that even on d.o?

sun’s picture

That's great to hear :)

Unfortunately, the situation for Inline 7.x-2.x is still the same:
http://qa.drupal.org/pifr/test/305443

I.e., the classloader dependency is not checked out and seems to be unknown.

Copying the relevant review log part in here, since the log info seems to get lost if the last test that was run was the Coder code review job:

    [review] => Array(
            [plugin] => pifr_simpletest
            [argument] => Array(
                    [test.title] => 
                    [test.directory.review] => Array(
                            [0] => sites/default/modules/inline
                        )
                    [test.directory.apply] => 
                    [test.directory.dependency] => 
                    [test.files] => Array()
                    [test.extensions] => Array(
                            [0] => php
                            [1] => inc
                            [2] => install
                            [3] => module
                            [4] => test
                        )
                    [drupal.core.version] => 7
                    [drupal.core.url] => git://git.drupal.org/project/drupal.git
                    [drupal.modules] => Array()
                    [drupal.user] => admin
                    [drupal.pass] => 
                    [drupal.variables] => Array()
                    [simpletest.tests] => Array()
                    [simpletest.db] => 
                )
        )
    [vcs] => Array(
            [main] => Array(
                    [repository] => Array(
                            [type] => git
                            [url] => git://git.drupal.org/project/drupal.git
                        )
                    [vcs_identifier] => 7.x
                )
            [dependencies] => Array(
                    [1] => Array(
                            [repository] => Array(
                                    [type] => git
                                    [url] => git://git.drupal.org/project/inline.git
                                )
                            [vcs_identifier] => 7.x-2.x
                        )
                )
        )
lucascaro’s picture

Title: Dependencies for sub module are not updated. » Dependencies for modules are not updated.

Hey there, just wanted to report that after the dependencies got updated (we still don't know how) we created a new 7.x-2.x branch that introduced a new dependency (xautoload) and the test bot is not detecting it (it's seeing no dependencies at all).

I'll give this branch a few more days in case the problem is that we need to wait. Just FYI the branch is already 2 days old and d.o does not see it yet (we can request tests but we can't create issues for it for example). Also it's not listed on the releases page when editing the project (http://drupal.org/node/325421/edit/releases).

Edit: Just updated the project text and re tested in case that triggered a dependency rebuild but it didn't. Anyways, here's the test link in case it's useful for debugging: http://qa.drupal.org/pifr/test/316978

So basically what we did was:

  • Started from a module with no dependencies in its 7.x-1.x branch.
  • Added a new branch, 7.x-2.x that depends on xautoload (the dependency is on the main .info file)
  • Waited 2 days
  • Triggered the tests for 7.x-2.x

At that point the tests failed. Maybe we need to do something else before testing?

sun’s picture

So that means you're facing the exact same situation like me. ;)

The only difference is that you're depending on xautoload and I'm depending on classloader. (btw, have a look at classloader ;))

lucascaro’s picture

Hey, today I requested a re-test and it passed!

Unless someone did something manually, it seems that it took one week to re generate dependencies when not creating a new branch and three days to read a new branch, but it worked...

[OT] @sun classloader seems really cool! We are using the wildcard feature that xautoloader adds, though :) (only to add files[] = tests/*.test)

sun’s picture

Odd. I've sent http://qa.drupal.org/pifr/test/305443 for re-testing, but its situation is still the same. :-/

I've also made sure to compare whether there's any difference between the two, but not really:

http://drupalcode.org/project/configuration.git/blob/refs/heads/7.x-2.x:...
http://drupalcode.org/project/inline.git/blob/refs/heads/7.x-2.x:/inline...

rfay’s picture

Status: Active » Fixed

Back from bike ride...

@sun, the dependencies for inline 7.x-2.x are correct,

drush pdsd inline 7.x-2.x-dev
Array
(
    [1711186] => Array
        (
            [uri] => classloader
            [version] => 7.x-1.1
            [tag] => 7.x-1.1
        )

)

Note that to get new dependencies on a retest you must initiate testing from d.o (not from qa.d.o, which would use the same info it already had.)

I note that this has apparently been done, as http://qa.drupal.org/pifr/test/305443 runs clean now.

lucascaro’s picture

Status: Fixed » Active

mhm... It looks that http://qa.drupal.org/pifr/test/305443 is still not loading the dependencies. I only see:

[dependencies] => Array
                (
                    [1] => Array
                        (
                            [repository] => Array
                                (
                                    [type] => git
                                    [url] => git://git.drupal.org/project/inline.git
                                )

                            [vcs_identifier] => 7.x-2.x
                        )

                )

and couldn't find classloader anywhere :( (also there are 0 pass(es); so it's not really running any tests).

But here are the good news, I just requested a re test from d.o and it picked up the new dependencies!

[dependencies] => Array
                (
                    [1] => Array
                        (
                            [repository] => Array
                                (
                                    [type] => git
                                    [url] => git://git.drupal.org/project/classloader.git
                                )

                            [vcs_identifier] => 7.x-1.1
                        )

                    [2] => Array
                        (
                            [repository] => Array
                                (
                                    [type] => git
                                    [url] => git://git.drupal.org/project/inline.git
                                )

                            [vcs_identifier] => 7.x-2.x
                        )

                )

I'm still wondering if the "drush pdsd inline 7.x-2.x-dev" made the difference or not.. this project was waiting for the new dependencies to be refreshed for a looong time....

rfay’s picture

Status: Active » Fixed

The pdsd did *not* affect it. But I *did* rebuild the dependencies for you back when. That doesn't do anything until the request comes in from d.o again.

Marking fixed, which I think is what you're saying.

lucascaro’s picture

oh thanks then :)

Status: Fixed » Closed (fixed)

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

Anonymous’s picture

Issue summary: View changes

Updated issue summary.