Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-6082

Join trigger never joins when a downstream project is disabled

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Duplicate
    • Component/s: join-plugin
    • Labels:
      None
    • Environment:
      Hudson 1.349, Join 1.8, Windows XP SP2
    • Similar Issues:

      Description

      Expected behavior: The join trigger can trigger when a downstream project is disabled

      Actual behavior: It never does

      Steps to reproduce:
      1) Create three normal projects JobA, JobB, JobC that execute the attached simple batch scripts.
      2) Create a project JobABC. Go to configure and
      a) check "Build other projects" specifying JobA and JobB as downstream projects.
      b) check "Join Trigger" specifying to run JobC when downstream projects are complete.
      c) save
      3) Build JobABC. Note that it runs JobA and JobB in parallel, then JobC when both are complete. This is expected.
      4) Go to JobA's configure page and check "Disable Build" and save
      5) Build JobABC again. This time JobB will correctly run... and JobA correctly does not run being disabled... but JobC will incorrectly never run because JoinAction is waiting for JobA's build result, which will never arrive.

        Attachments

          Issue Links

            Activity

            Hide
            natashadev natashadev added a comment -

            Hi,

            In my own env I was able to resolve this problem by modifying JoinAction's constructor to comment out these two lines:

            //String[] downstreamProjects = buildTrigger==null ?
            // new String[0] : buildTrigger.getChildProjectsValue().split(",");

            and instead do this:

            //Filter out disabled builds

            //Get a list of all projects, enabled and disabled
            List<AbstractProject> rawDownstreamProjects = buildTrigger==null ?
            new ArrayList<AbstractProject>() : buildTrigger.getChildProjects();

            //and a separate array of names
            String[] rawDownstreamProjectNames = buildTrigger==null ?
            new String[0] : buildTrigger.getChildProjectsValue().split(",");

            //Populate a new list with only the names of enabled projects
            List<String> enabledProjects = new ArrayList<String>();

            for( int i=0; i<rawDownstreamProjects.size(); i++ ){
            if(!rawDownstreamProjects.get.isDisabled())

            { enabledProjects.add(rawDownstreamProjectNames[i]); }

            else

            { //no need to track disabled projects }

            }

            String[] downstreamProjects = enabledProjects.toArray(new String[0]);

            Show
            natashadev natashadev added a comment - Hi, In my own env I was able to resolve this problem by modifying JoinAction's constructor to comment out these two lines: //String[] downstreamProjects = buildTrigger==null ? // new String [0] : buildTrigger.getChildProjectsValue().split(","); and instead do this: //Filter out disabled builds //Get a list of all projects, enabled and disabled List<AbstractProject> rawDownstreamProjects = buildTrigger==null ? new ArrayList<AbstractProject>() : buildTrigger.getChildProjects(); //and a separate array of names String[] rawDownstreamProjectNames = buildTrigger==null ? new String [0] : buildTrigger.getChildProjectsValue().split(","); //Populate a new list with only the names of enabled projects List<String> enabledProjects = new ArrayList<String>(); for( int i=0; i<rawDownstreamProjects.size(); i++ ){ if(!rawDownstreamProjects.get .isDisabled()) { enabledProjects.add(rawDownstreamProjectNames[i]); } else { //no need to track disabled projects } } String[] downstreamProjects = enabledProjects.toArray(new String [0] );
            Hide
            natashadev natashadev added a comment -

            If you agree with this approach feel free to reassign the bug to me to check in.

            Show
            natashadev natashadev added a comment - If you agree with this approach feel free to reassign the bug to me to check in.
            Hide
            mdonohue mdonohue added a comment -

            There was another bug filed with a patch, which I've applied. I will release another version of the plugin soon.

            Show
            mdonohue mdonohue added a comment - There was another bug filed with a patch, which I've applied. I will release another version of the plugin soon.

              People

              • Assignee:
                mdonohue mdonohue
                Reporter:
                natashadev natashadev
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: