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

git-plugin fails to expand variables in refspec on initial clone

    Details

    • Similar Issues:

      Description

      Git plugin fails to expand variables in the refspec setting. A sure way to trigger the bug is to enable both "Honor refspec on initial clone" and "Wipe out repository & force clone". The config is attached.

      Here's an excerpt from the log to the top-level job:

       

       > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master${BUILD_ID} # timeout=10
       > git config remote.origin.url http://stash/scm/rob/testrepository.git # timeout=10
       > git config --add remote.origin.fetch +refs/heads/master:refs/remotes/origin/master${BUILD_ID} # timeout=10
       > git config remote.origin.url http://stash/scm/rob/testrepository.git # timeout=10
      Cleaning workspace
       > git rev-parse --verify HEAD # timeout=10
      No valid HEAD. Skipping the resetting
       > git clean -fdx # timeout=10
      Pruning obsolete local branches
      Fetching upstream changes from http://stash/scm/rob/testrepository.git
       > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master6 --prune # timeout=10
      
      

      Note that ${BUILD_ID} is not expanded in the first commit, but is expanded at the end where branch specifier is being used.

       

      Remove "Wipe out repository & force clone", and the variable is being expanded now.

       

       > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master9 --prune # timeout=10
       > git rev-parse refs/remotes/origin/master9^{commit} # timeout=10
       > git rev-parse refs/remotes/origin/refs/heads/master9^{commit} # timeout=10
      

       

      It may seem a trivial issue with ${BUILD_ID}, but it's actually a big problem when I try pulling ${sourceCommitHash} with stash-pull-request-builder. That's why I consider it a major bug. It prevents me from using the correct commit received from Stash REST API and makes me use a suboptimal solution that involves a race condition.

      I believe git-plugin should always expand variables in the refspec setting on its own, without relying on the shell.

       

        Attachments

          Activity

          proski Pavel Roskin created issue -
          markewaite Mark Waite made changes -
          Field Original Value New Value
          Assignee Mark Waite [ markewaite ]
          markewaite Mark Waite made changes -
          Labels expansion git-plugin variables expansion git-plugin newbie-friendly variables
          rishabhbudhouliya Rishabh Budhouliya made changes -
          Assignee Rishabh Budhouliya [ rishabhbudhouliya ]
          rishabhbudhouliya Rishabh Budhouliya made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          rishabhbudhouliya Rishabh Budhouliya made changes -
          Status In Progress [ 3 ] In Review [ 10005 ]
          deepansh_nagaria Deepansh Nagaria made changes -
          Description Git plugin fails to expand variables in the refspec setting. A sure way to trigger the bug is to enable both "Honor refspec on initial clone" and "Wipe out repository & force clone". The config is attached.

          Here's an excerpt from the log to the top-level job:

           
          {code:java}
           > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master${BUILD_ID} # timeout=10
           > git config remote.origin.url http://stash/scm/rob/testrepository.git # timeout=10
           > git config --add remote.origin.fetch +refs/heads/master:refs/remotes/origin/master${BUILD_ID} # timeout=10
           > git config remote.origin.url http://stash/scm/rob/testrepository.git # timeout=10
          Cleaning workspace
           > git rev-parse --verify HEAD # timeout=10
          No valid HEAD. Skipping the resetting
           > git clean -fdx # timeout=10
          Pruning obsolete local branches
          Fetching upstream changes from http://stash/scm/rob/testrepository.git
           > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master6 --prune # timeout=10

          {code}
          Note that ${BUILD_ID} is not expanded in the first commit, but is expanded at the end where branch specifier is being used.

           

          Remove "Wipe out repository & force clone", and the variable is being expanded now.

           
          {code:java}
           > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master9 --prune # timeout=10
           > git rev-parse refs/remotes/origin/master9^{commit} # timeout=10
           > git rev-parse refs/remotes/origin/refs/heads/master9^{commit} # timeout=10
          {code}
           

          It may seem a trivial issue with ${BUILD_ID}, but it's actually a big problem when I try pulling ${sourceCommitHash} with stash-pull-request-builder. That's why I consider it a major bug. It prevents me from using the correct commit received from Stash REST API and makes me use a suboptimal solution that involves a race condition.

          I believe git-plugin should always expand variables in the refspec setting on its own, without relying on the shell.

           

          0...........................................................................0Git plugin fails to expand variables in the refspec setting. A sure way to trigger the bug is to enable both "Honor refspec on initial clone" and "Wipe out repository & force clone". The config is attached.

          Here's an excerpt from the log to the top-level job:

           
          {code:java}
           > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master${BUILD_ID} # timeout=10
           > git config remote.origin.url http://stash/scm/rob/testrepository.git # timeout=10
           > git config --add remote.origin.fetch +refs/heads/master:refs/remotes/origin/master${BUILD_ID} # timeout=10
           > git config remote.origin.url http://stash/scm/rob/testrepository.git # timeout=10
          Cleaning workspace
           > git rev-parse --verify HEAD # timeout=10
          No valid HEAD. Skipping the resetting
           > git clean -fdx # timeout=10
          Pruning obsolete local branches
          Fetching upstream changes from http://stash/scm/rob/testrepository.git
           > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master6 --prune # timeout=10

          {code}
          Note that ${BUILD_ID} is not expanded in the first commit, but is expanded at the end where branch specifier is being used.

           

          Remove "Wipe out repository & force clone", and the variable is being expanded now.

           
          {code:java}
           > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master9 --prune # timeout=10
           > git rev-parse refs/remotes/origin/master9^{commit} # timeout=10
           > git rev-parse refs/remotes/origin/refs/heads/master9^{commit} # timeout=10
          {code}
           

          It may seem a trivial issue with ${BUILD_ID}, but it's actually a big problem when I try pulling ${sourceCommitHash} with stash-pull-request-builder. That's why I consider it a major bug. It prevents me from using the correct commit received from Stash REST API and makes me use a suboptimal solution that involves a race condition.

          I believe git-plugin should always expand variables in the refspec setting on its own, without relying on the shell.

           
          markewaite Mark Waite made changes -
          Description
          0...........................................................................0Git plugin fails to expand variables in the refspec setting. A sure way to trigger the bug is to enable both "Honor refspec on initial clone" and "Wipe out repository & force clone". The config is attached.

          Here's an excerpt from the log to the top-level job:

           
          {code:java}
           > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master${BUILD_ID} # timeout=10
           > git config remote.origin.url http://stash/scm/rob/testrepository.git # timeout=10
           > git config --add remote.origin.fetch +refs/heads/master:refs/remotes/origin/master${BUILD_ID} # timeout=10
           > git config remote.origin.url http://stash/scm/rob/testrepository.git # timeout=10
          Cleaning workspace
           > git rev-parse --verify HEAD # timeout=10
          No valid HEAD. Skipping the resetting
           > git clean -fdx # timeout=10
          Pruning obsolete local branches
          Fetching upstream changes from http://stash/scm/rob/testrepository.git
           > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master6 --prune # timeout=10

          {code}
          Note that ${BUILD_ID} is not expanded in the first commit, but is expanded at the end where branch specifier is being used.

           

          Remove "Wipe out repository & force clone", and the variable is being expanded now.

           
          {code:java}
           > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master9 --prune # timeout=10
           > git rev-parse refs/remotes/origin/master9^{commit} # timeout=10
           > git rev-parse refs/remotes/origin/refs/heads/master9^{commit} # timeout=10
          {code}
           

          It may seem a trivial issue with ${BUILD_ID}, but it's actually a big problem when I try pulling ${sourceCommitHash} with stash-pull-request-builder. That's why I consider it a major bug. It prevents me from using the correct commit received from Stash REST API and makes me use a suboptimal solution that involves a race condition.

          I believe git-plugin should always expand variables in the refspec setting on its own, without relying on the shell.

           
          Git plugin fails to expand variables in the refspec setting. A sure way to trigger the bug is to enable both "Honor refspec on initial clone" and "Wipe out repository & force clone". The config is attached.

          Here's an excerpt from the log to the top-level job:

           
          {code:java}
           > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master${BUILD_ID} # timeout=10
           > git config remote.origin.url http://stash/scm/rob/testrepository.git # timeout=10
           > git config --add remote.origin.fetch +refs/heads/master:refs/remotes/origin/master${BUILD_ID} # timeout=10
           > git config remote.origin.url http://stash/scm/rob/testrepository.git # timeout=10
          Cleaning workspace
           > git rev-parse --verify HEAD # timeout=10
          No valid HEAD. Skipping the resetting
           > git clean -fdx # timeout=10
          Pruning obsolete local branches
          Fetching upstream changes from http://stash/scm/rob/testrepository.git
           > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master6 --prune # timeout=10

          {code}
          Note that ${BUILD_ID} is not expanded in the first commit, but is expanded at the end where branch specifier is being used.

           

          Remove "Wipe out repository & force clone", and the variable is being expanded now.

           
          {code:java}
           > git fetch --no-tags --progress http://stash/scm/rob/testrepository.git +refs/heads/master:refs/remotes/origin/master9 --prune # timeout=10
           > git rev-parse refs/remotes/origin/master9^{commit} # timeout=10
           > git rev-parse refs/remotes/origin/refs/heads/master9^{commit} # timeout=10
          {code}
           

          It may seem a trivial issue with ${BUILD_ID}, but it's actually a big problem when I try pulling ${sourceCommitHash} with stash-pull-request-builder. That's why I consider it a major bug. It prevents me from using the correct commit received from Stash REST API and makes me use a suboptimal solution that involves a race condition.

          I believe git-plugin should always expand variables in the refspec setting on its own, without relying on the shell.

           

            People

            • Assignee:
              rishabhbudhouliya Rishabh Budhouliya
              Reporter:
              proski Pavel Roskin
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: