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

additional refspecs at the organisational level is unworkable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Not A Defect
    • Component/s: git-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      I'm using a github organization with declarative pipeline to build many projects in our organisation.  I need some (one currently) project to fetch additional refspecs so that a job can do git operations on them.

      This however breaks for any projects that don't have all of the additional refspecs in them.

      It seems unrealistic to expect every project within an organisation to have all of the additional refspecs.

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment -

          Brian J Murrell you can use a unique refspec in the declarative pipeline checkout of a specific branch by using the skipDefaultCheckout directive in the declarative pipeline of that branch. After the skipDefaultCheckout, then you place a checkout step inside the declarative pipeline which uses the exact refspec that you want.

          Refer to my repository for a Jenkinsfile that defines a refspec with declarative pipeline.

          Show
          markewaite Mark Waite added a comment - Brian J Murrell you can use a unique refspec in the declarative pipeline checkout of a specific branch by using the skipDefaultCheckout directive in the declarative pipeline of that branch. After the skipDefaultCheckout , then you place a checkout step inside the declarative pipeline which uses the exact refspec that you want. Refer to my repository for a Jenkinsfile that defines a refspec with declarative pipeline.
          Hide
          markewaite Mark Waite added a comment -

          The skipDefaultCheckout technique may need to be described more visibly in advanced tutorials or in an intermediate declarative pipeline segment.

          It is intentional that a declarative pipeline includes an implicit checkout. That makes sense for the vast majority of cases. In those cases where it does not make sense (like this one described by Brian), skipDefaultCheckout allows full control of the checkout step.

          Show
          markewaite Mark Waite added a comment - The skipDefaultCheckout technique may need to be described more visibly in advanced tutorials or in an intermediate declarative pipeline segment. It is intentional that a declarative pipeline includes an implicit checkout. That makes sense for the vast majority of cases. In those cases where it does not make sense (like this one described by Brian), skipDefaultCheckout allows full control of the checkout step.
          Hide
          brianjmurrell Brian J Murrell added a comment -

          Fair enough.  How can one find out what the parameters to  the default checkout are being used?  IOW, if I wanted to start with replicating exactly what the default checkout does and then alter it to my needs, how would I know what that default checkout looks like?

          Show
          brianjmurrell Brian J Murrell added a comment - Fair enough.  How can one find out what the parameters to  the default checkout are being used?  IOW, if I wanted to start with replicating exactly what the default checkout does and then alter it to my needs, how would I know what that default checkout looks like?
          Hide
          markewaite Mark Waite added a comment - - edited

          Brian J Murrell There are several sample jobs like this one, this one, and this one which show techniques like echoing the values of parts of the scm object to see them.

          Since the default checkout settings are defined in the multibranch pipeline job itself, the scm object is the best way to find them. Many of my multibranch pipeline jobs define a reference repository and declare that the checkout should honor the refsepec in checkout. Others do not.

          Show
          markewaite Mark Waite added a comment - - edited Brian J Murrell There are several sample jobs like this one , this one , and this one which show techniques like echoing the values of parts of the scm object to see them. Since the default checkout settings are defined in the multibranch pipeline job itself, the scm object is the best way to find them. Many of my multibranch pipeline jobs define a reference repository and declare that the checkout should honor the refsepec in checkout. Others do not.
          Hide
          brianjmurrell Brian J Murrell added a comment -

          OK.  So then, is using a "bare" checkout command effectively do the same thing as not specifying skipDefaultCheckout?

          Show
          brianjmurrell Brian J Murrell added a comment - OK.  So then, is using a "bare" checkout command effectively do the same thing as not specifying skipDefaultCheckout ?
          Hide
          markewaite Mark Waite added a comment - - edited

          A declarative pipeline with skipDefaultCheckout and the first step as checkout scm is the same as not declaring skipDefaultCheckout and not specifying checkout scm as the first step.

          Show
          markewaite Mark Waite added a comment - - edited A declarative pipeline with skipDefaultCheckout and the first step as checkout scm is the same as not declaring skipDefaultCheckout and not specifying checkout scm as the first step.

            People

            • Assignee:
              markewaite Mark Waite
              Reporter:
              brianjmurrell Brian J Murrell
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: