The Workbench Moderation 7.x-2.x branch used to have dependencies[] = state_machine in it's info file. Which mean that the test bot checked out the latest stable release of state machine, which was 7.x-2.0. Unfortunately that wasn't the right branch that we needed so we modified it to be dependencies[] = state_machine (3.x) and once the dev build regenerated, I can see that the testbot attempts to checkout the state_machine 7.x-3.x from Git. But the problem is it's also still checking out state_machine 7.x-2.0 right before it tries to checkout 7.x-3.x, which causes an error since it can't checkout a module twice to the same directory.

From http://qa.drupal.org/pifr/test/201353:

    'dependencies' => array(
      0 => array(
        'repository' => array(
          'type' => 'git',
          'url' => 'git://git.drupal.org/project/drupal.git',
        ),
        'vcs_identifier' => '7.x',
      ),
      1 => array(
        'repository' => array(
          'type' => 'git',
          'url' => 'git://git.drupal.org/project/ctools.git',
        ),
        'vcs_identifier' => '7.x-1.2',
      ),
      2 => array(
        'repository' => array(
          'type' => 'git',
          'url' => 'git://git.drupal.org/project/state_machine.git',
        ),
        'vcs_identifier' => '7.x-3.x',
      ),
      3 => array(
        'repository' => array(
          'type' => 'git',
          'url' => 'git://git.drupal.org/project/state_machine.git',
        ),
        'vcs_identifier' => '7.x-2.0',
      ),
      4 => array(
        'repository' => array(
          'type' => 'git',
          'url' => 'git://git.drupal.org/project/views.git',
        ),
        'vcs_identifier' => '7.x-3.5',
      ),
    ),
  ),

There is no other dependencies[] in the workbench_moderation module that should be causing this. It seems like if I change the version of a requirement in a module, it doesn't update the existing, but just adds a new dependency record in the testbot.

Comments

jthorson’s picture

The Jenkins 'Rebuild dependencies' script didn't solve the issue ... Randy has occasionally had to take the next step of removing the source code cache that project_dependency operates on. Unfortunately, I don't have sufficient permissions to kick this off yet ... will come back to this once I get that cleared up.

Dave Reid’s picture

Ok thanks for the update jthorson!

jthorson’s picture

Well ... I cleared the sourcecode cache, rebuilt the dependencies, and still end up with two state_machine entries:

Array
(
    [1738460] => Array
        (
            [uri] => ctools
            [version] => 7.x-1.2
            [tag] => 7.x-1.2
            [dependency_type] => 0
        )

    [1427384] => Array
        (
            [uri] => state_machine
            [version] => 7.x-3.x-dev
            [tag] => 7.x-3.x
            [dependency_type] => 0
        )

    [1840116] => Array
        (
            [uri] => state_machine
            [version] => 7.x-2.0
            [tag] => 7.x-2.0
            [dependency_type] => 0
        )

    [1751522] => Array
        (
            [uri] => views
            [version] => 7.x-3.5
            [tag] => 7.x-3.5
            [dependency_type] => 0
        )

)

If I get a chance, I'll start through project_dependency code to try and figure out why we're getting this result ... but I can't promise it will be any time soon.

jthorson’s picture

Project: Drupal.org Testbots » Project Dependency
Version: » 6.x-1.x-dev
Component: unexplained test failure » Code
Category: support » bug

I suspect what is happening is that we're getting the state_machine 3.x dependency from workflow_moderation, and the state_machine 2.x dependency is being pulled in from from state_flow 3.x ... state_flow 3.x depends on state_machine (no version specified), and thus the recommended state_machine 2.0 release trumps the state_machine 3.x release in the dependency calculation.

Alternatively, if the State Flow 3.x branch specified state_machine (3.x) as the dependency, that would probably straighten this out as well ... if that is the intent in their rewrite, it may be worth having them update the state_flow.info file.

Still, project_dependency needs to be able to detect this scenario and not duplicate the dependency entry ... so re-routing there as a bug report.

Dave Reid’s picture

Yeah, the silly problem is that state_flow is a sub-module of state_machine, so why would a project need to list a versioned dependency of a module it contains?