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

Helix branches do not recurse when defining multibranch pipeline

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • p4-plugin

      If I have a multibranch pipeline and set Helix Branch as the source, and provide it with //depot/… as my branch to include, it only seems to scan one layer deep (it picks up //depot/project/Jenksinfile , but does not pick up //depot/project/dev/username/Jenkinsfile).

      The help tip for this input claims that "A List of Perforce Depot paths (separated by new lines). The plugin will recursively search for a Jenkinsfile (or defined item) using the last directory name for the multi-branch name."

      This does not seem to be true.

      I can trick it by defining separate entries for each depth of hierarchy I might expect:

      //depot/*
//depot/*/*
//depot/*/*/*
etc

      I care about this because I want to use a single job definition for all of my client projects, each of which is free to use a Jenkinsfile of their choosing, to reduce maintenance. Not all projects follow an identical depth of hierarchy.

          [JENKINS-52605] Helix branches do not recurse when defining multibranch pipeline

          Matt Pollock created issue -
          Paul Allen made changes -
          Description Original: If I have a multibranch pipeline and set Helix Branch as the source, and provide it with //depot/… as my branch to include, it only seems to scan one layer deep (it picks up //depot/project/Jenksinfile , but does not pick up //depot/project/dev/username/Jenkinsfile).


          The help tip for this input claims that "A List of Perforce Depot paths (separated by new lines). The plugin will recursively search for a Jenkinsfile (or defined item) using the last directory name for the multi-branch name."

          This does not seem to be true.

          I can trick it by defining separate entries for each depth of hierarchy I might expect:

          //depot/*
          //depot/*/*
          //depot/*/*/*
          etc

          I care about this because I want to use a single job definition for all of my client projects, each of which is free to use a Jenkinsfile of their choosing, to reduce maintenance. Not all projects follow an identical depth of hierarchy.           		New: If I have a multibranch pipeline and set Helix Branch as the source, and provide it with //depot/… as my branch to include, it only seems to scan one layer deep (it picks up //depot/project/Jenksinfile , but does not pick up //depot/project/dev/username/Jenkinsfile).


          The help tip for this input claims that "A List of Perforce Depot paths (separated by new lines). The plugin will recursively search for a Jenkinsfile (or defined item) using the last directory name for the multi-branch name."

          This does not seem to be true.

          I can trick it by defining separate entries for each depth of hierarchy I might expect:
          {code}
          //depot/*
          //depot/*/*
          //depot/*/*/*
          etc
          {code}
          I care about this because I want to use a single job definition for all of my client projects, each of which is free to use a Jenkinsfile of their choosing, to reduce maintenance. Not all projects follow an identical depth of hierarchy.
          Paul Allen made changes -
          Assignee New: Paul Allen [ p4paul ]
          Paul Allen made changes -
          Labels New: P4_B
          Paul Allen made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Kevin Williamson made changes -
          Assignee Original: Paul Allen [ p4paul ] New: Kevin Williamson [ p4kevin ]
          Paul Allen made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: In Progress [ 3 ] New: Closed [ 6 ]

            p4kevin Kevin Williamson
            pollockm Matt Pollock
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: