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
Comment #1
boombatower commentedThe 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.
Comment #2
sunI 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... :-/
Comment #3
lucascaro commentedYeah, 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?
Comment #4
rfay@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.
Comment #5
sunThe 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:
I'm not too familiar with @lucascaro's case, but I can precisely explain mine:
Comment #6
lucascaro commented@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?
Comment #7
sunThat'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:
Comment #8
lucascaro commentedHey 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:
At that point the tests failed. Maybe we need to do something else before testing?
Comment #9
sunSo 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 ;))
Comment #10
lucascaro commentedHey, 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)
Comment #11
sunOdd. 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...
Comment #12
rfayBack from bike ride...
@sun, the dependencies for inline 7.x-2.x are correct,
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.
Comment #13
lucascaro commentedmhm... It looks that http://qa.drupal.org/pifr/test/305443 is still not loading the dependencies. I only see:
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!
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....
Comment #14
rfayThe 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.
Comment #15
lucascaro commentedoh thanks then :)
Comment #16.0
(not verified) commentedUpdated issue summary.