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

Specify a remote name different from the repository slug

      Hello,

      I was wondering how to manage the refspec for a repository cloned using the Bitbucket Server plugin? We would like to clone into origin instead of the branch name.

      Thank you!

          [JENKINS-67890] Specify a remote name different from the repository slug

          I cannot reproduce this with a multibranch pipeline project on Jenkins 2.332.1, Git client plugin 3.11.0, Git plugin 4.11.0, and Bitbucket Server Integration 3.2.0. The remote name is "origin" unless I add the "Configure remote name" behaviour (I think that's RemoteNameSCMSourceTrait).

          Are you using a different type of project?

          Kalle Niemitalo added a comment - I cannot reproduce this with a multibranch pipeline project on Jenkins 2.332.1, Git client plugin 3.11.0, Git plugin 4.11.0, and Bitbucket Server Integration 3.2.0. The remote name is "origin" unless I add the "Configure remote name" behaviour (I think that's RemoteNameSCMSourceTrait ). Are you using a different type of project?

          Josh Mueller added a comment -

          The versions I am working with are:

          • Jenkins 2.303.3
          • Bitbucket Server Integration 3.2.0
          • Git plugin 4.10.3
          • git version 2.14.4

          I see this behavior in both freestyle projects and pipeline projects.

          A quick sample of the jenkinsfile for the pipeline job that has the issue:

          pipeline {
              agent any
              stages {
                  stage( 'Jenkins setup' ) {
                      steps {
                          script {
                              checkout BbS(
                                  branches: [[name: "<repo>/master"]],
                                  credentialsId: '<credentials>',
                                  extensions: [
                                      [$class: 'CloneOption', depth: 10, noTags: false, reference: '', shallow: true],
                                      [$class: 'RelativeTargetDirectory', relativeTargetDir: '<dir>'],
                                      [$class: 'CleanBeforeCheckout'],
                                      [$class: 'PruneStaleBranch']
                                  ],
                                  id: '<id>',
                                  mirrorName: '',
                                  projectName: '<project>',
                                  repositoryName: '<repo>',
                                  serverId: '<server id>',
                                  sshCredentialsId: '<credentials>'
                              )
                          }
                      }
                  }
              }
          }
          

          Josh Mueller added a comment - The versions I am working with are: Jenkins 2.303.3 Bitbucket Server Integration 3.2.0 Git plugin 4.10.3 git version 2.14.4 I see this behavior in both freestyle projects and pipeline projects. A quick sample of the jenkinsfile for the pipeline job that has the issue: pipeline { agent any stages { stage( 'Jenkins setup' ) { steps { script { checkout BbS( branches: [[name: "<repo>/master" ]], credentialsId: '<credentials>' , extensions: [ [$class: 'CloneOption' , depth: 10, noTags: false , reference: '', shallow: true ], [$class: 'RelativeTargetDirectory' , relativeTargetDir: '<dir>' ], [$class: 'CleanBeforeCheckout' ], [$class: 'PruneStaleBranch' ] ], id: '<id>' , mirrorName: '', projectName: '<project>' , repositoryName: '<repo>' , serverId: '<server id>' , sshCredentialsId: '<credentials>' ) } } } } }

          I see. Perhaps it comes from BitbucketSCM.initializeGitScm, which passes getRepositorySlug() as String name to the UserRemoteConfig constructor.

          BitbucketSCMSource.initializeGitScmSource does the same, but that does not seem to affect the clone on the agent. Does it affect something on the controller, instead?

          In the Bitbucket Branch Source plugin, BitbucketGitSCMBuilder doesn't seem to configure the remote name, except when building a pull request merge. I suppose GitSCMBuilder.remoteName then retains its default value.

          Kalle Niemitalo added a comment - I see. Perhaps it comes from BitbucketSCM.initializeGitScm , which passes getRepositorySlug() as String name to the UserRemoteConfig constructor . BitbucketSCMSource.initializeGitScmSource does the same, but that does not seem to affect the clone on the agent. Does it affect something on the controller, instead? In the Bitbucket Branch Source plugin, BitbucketGitSCMBuilder doesn't seem to configure the remote name, except when building a pull request merge. I suppose GitSCMBuilder.remoteName then retains its default value.

          I retitled this issue to match what minielim described. I hope this is also what keblack789 meant.

          Kalle Niemitalo added a comment - I retitled this issue to match what minielim described. I hope this is also what keblack789 meant.

          Katie Black added a comment -

          Yes this is what i meant! are there any updates on this issue?

          Katie Black added a comment - Yes this is what i meant! are there any updates on this issue?

          Hi,

          Same "issue" here. I would like to override the remote name (to use 'origin') instead of the name of the repository.

          Regards,

          Valentin Delaye added a comment - Hi, Same "issue" here. I would like to override the remote name (to use 'origin') instead of the name of the repository. Regards,

          Gabriel added a comment - - edited

          This creates a bug also for the submodule update. The submodule init searches for the "origin" remote entry in order to resolve the relative paths for submodules.

          Since this plugin set entries like:

          [remote "reponame"]
              url = ssh://git@bitbucket.example.com/projname/reponame.git 

          instead of

          [remote "origin"]
              url = ssh://git@bitbucket.example.com/projname/reponame.git
              fetch = +refs/heads/*:refs/remotes/origin/*
          

          the git submodule init fails with:

          warning: could not look up configuration 'remote.origin.url'. Assuming this repository is its own authoritative upstream. 

          This happens also if the submodule init is set at the job level (job config).

          System Configuration:

          • Jenkins 2.346.3
          • Bitbucket Server Integration Plugin Version 3.3.2
          • Git plugin Version 4.14.2
          • Git version 2.38.1

          Gabriel added a comment - - edited This creates a bug also for the submodule update. The submodule init searches for the "origin" remote entry in order to resolve the relative paths for submodules. Since this plugin set entries like: [remote "reponame" ]     url = ssh: //git@bitbucket.example.com/projname/reponame.git instead of [remote "origin" ]     url = ssh: //git@bitbucket.example.com/projname/reponame.git   fetch = +refs/heads/*:refs/remotes/origin/* the git submodule init fails with: warning: could not look up configuration 'remote.origin.url' . Assuming this repository is its own authoritative upstream. This happens also if the submodule init is set at the job level (job config). System Configuration: Jenkins 2.346.3 Bitbucket Server Integration Plugin Version 3.3.2 Git plugin Version 4.14.2 Git version 2.38.1

          sigusro, can you reproduce the error with submodules if you don't use the Bitbucket Server Integration plugin at all, and instead use the "Git" branch source and add the "Configure remote name" behaviour? If so, I think it should be filed as a separate bug.

          Kalle Niemitalo added a comment - sigusro , can you reproduce the error with submodules if you don't use the Bitbucket Server Integration plugin at all, and instead use the "Git" branch source and add the "Configure remote name" behaviour? If so, I think it should be filed as a separate bug.

          Gabriel added a comment - - edited

          Kalle, thank you for your reply.

          This behavior happens only when using this plugin. It works OK using others like the simple Git plugin.

          I don't see a reason for a separate bug since the root cause is the usage of the slug instead of defaulting to "origin", hence the the topic of this ticket.

          Gabriel added a comment - - edited Kalle, thank you for your reply. This behavior happens only when using this plugin. It works OK using others like the simple Git plugin. I don't see a reason for a separate bug since the root cause is the usage of the slug instead of defaulting to "origin", hence the the topic of this ticket.

          Any update here ? All other SCM/Git related plugin allow overriding the name of the remote

          Valentin Delaye added a comment - Any update here ? All other SCM/Git related plugin allow overriding the name of the remote

            keblack789 Katie Black
            keblack789 Katie Black
            Votes:
            3 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: