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

git parameter plugin does not apply remote setting changes

    Details

    • Similar Issues:

      Description

      After migrating our Bitbucket instance to a new server with a new IP address, we're not able to change the IP address to point jenkins at the new server. the Bitbucket server is behind a proxy `bitbucket.our.domain` and the url has not changed. in the pipeline, we define the scm in the first step of the first stage:

      scm: [ $class: 'GitSCM', branches: [[name: "${BRANCH}"]], userRemoteConfigs: [[credentialsId: '*******************************',url: 'ssh://git@bitbucket.our.domain:7999/project/repository.git']] ]
      

      with pipelines, the Source Code Management section does not exist, so this is the only place that the remote url is defined. Yet, when trying to Build with Parameters we get the attatched error, which is clearly not the url that has been defined.

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment - - edited

          I assume that you are using static agents and thus are reusing workspaces. The git plugin is not sophisticated enough to apply the change of remote URL (or any other remote settings) to the existing workspace. If that is the case, then you can temporarily modify the pipeline script to precede the checkout scm step with a deleteDir step. That will erase the working repository in the workspace, it will then be cloned from the new URL and will write the new URL into the workspace.

          Same problem exists when a job definition changes from using a shallow clone to not using a shallow clone, or from not using a reference repository to using a reference repository. The git client plugin and the git plugin record state data about the repository in the workspace but do not force the repository in the workspace to match the current values of the plugin state data.

          Show
          markewaite Mark Waite added a comment - - edited I assume that you are using static agents and thus are reusing workspaces. The git plugin is not sophisticated enough to apply the change of remote URL (or any other remote settings) to the existing workspace. If that is the case, then you can temporarily modify the pipeline script to precede the checkout scm step with a deleteDir step. That will erase the working repository in the workspace, it will then be cloned from the new URL and will write the new URL into the workspace. Same problem exists when a job definition changes from using a shallow clone to not using a shallow clone, or from not using a reference repository to using a reference repository. The git client plugin and the git plugin record state data about the repository in the workspace but do not force the repository in the workspace to match the current values of the plugin state data.
          Hide
          tbretz94 Tim Bretz added a comment -

          Mark Waite I can't reach the `deleteDir` step even though it is the first step, because I can't get passed the required parameters. I tried copying the pipeline into a new job and it was unable to read any configuration at all. 

          No Git repository configured in SCM configuration or plugin is configured wrong

           

          Show
          tbretz94 Tim Bretz added a comment - Mark Waite I can't reach the `deleteDir` step even though it is the first step, because I can't get passed the required parameters. I tried copying the pipeline into a new job and it was unable to read any configuration at all.  No Git repository configured in SCM configuration or plugin is configured wrong  
          Hide
          markewaite Mark Waite added a comment -

          Tim Bretz that may indicate an issue in the git parameter plugin. Are you providing the repository URL as a parameter to the job? If so, then you might try redefining the job temporarily to not parameterize the repository URL, run it with the corrected URL, then add the repository URL parameter to the job again. There may be some internal storage of the repository URL in the git parameter plugin which is not being adjusted when you change the repository URL elsewhere.

          Show
          markewaite Mark Waite added a comment - Tim Bretz that may indicate an issue in the git parameter plugin. Are you providing the repository URL as a parameter to the job? If so, then you might try redefining the job temporarily to not parameterize the repository URL, run it with the corrected URL, then add the repository URL parameter to the job again. There may be some internal storage of the repository URL in the git parameter plugin which is not being adjusted when you change the repository URL elsewhere.
          Hide
          tbretz94 Tim Bretz added a comment -

          Mark Waite The repository URL is only specified in the `scm` step and is not a paramter. Neither plugin has configurations available in the UI related to the remote URL. My only possible solution at this point is to change the IP of the new Bitbucket server, which amazes me that we can never change the IP because these plugins are not configurable on level beyond what is entered in the pipeline, and even then the configuration in the pipeline doesn't apply to the plugins.

          Show
          tbretz94 Tim Bretz added a comment - Mark Waite The repository URL is only specified in the `scm` step and is not a paramter. Neither plugin has configurations available in the UI related to the remote URL. My only possible solution at this point is to change the IP of the new Bitbucket server, which amazes me that we can never change the IP because these plugins are not configurable on level beyond what is entered in the pipeline, and even then the configuration in the pipeline doesn't apply to the plugins.
          Hide
          tbretz94 Tim Bretz added a comment -

          deleting the workspace did not resolve this issue

          Show
          tbretz94 Tim Bretz added a comment - deleting the workspace did not resolve this issue
          Hide
          tbretz94 Tim Bretz added a comment -

          For clarification, the new Bitbucket server was working for at least a week at the new IP address before this became an issue, and there are other jobs using the same configuration as this, but without the git parameters plugin. I don't think this has to do with the git plugin given that it is functioning correctly on the same jenkins instance in other jobs, although having the ability to configure the git plugin beyond what is given in the pipeline may alleviate the issue that causes other plugins to break.

          Show
          tbretz94 Tim Bretz added a comment - For clarification, the new Bitbucket server was working for at least a week at the new IP address before this became an issue, and there are other jobs using the same configuration as this, but without the git parameters plugin. I don't think this has to do with the git plugin given that it is functioning correctly on the same jenkins instance in other jobs, although having the ability to configure the git plugin beyond what is given in the pipeline may alleviate the issue that causes other plugins to break.
          Hide
          markewaite Mark Waite added a comment -

          The old address or hostname must be stored somewhere in the Jenkins system. If you have access to the JENKINS_HOME directory and can safely search it, you might search for it and use that location to make a guess about what needs to be changed to correct the problem.

          It seems to me that the repository URL must be stored somewhere, otherwise Jenkins would not be able find the Jenkinsfile which contains the scm step. Where ever that is (job definition if a Pipeline job, multi-branch job definition if a multi-branch pipeline, organization folder if an Org Folder), assure it is the correct URL.

          Show
          markewaite Mark Waite added a comment - The old address or hostname must be stored somewhere in the Jenkins system. If you have access to the JENKINS_HOME directory and can safely search it, you might search for it and use that location to make a guess about what needs to be changed to correct the problem. It seems to me that the repository URL must be stored somewhere, otherwise Jenkins would not be able find the Jenkinsfile which contains the scm step. Where ever that is (job definition if a Pipeline job, multi-branch job definition if a multi-branch pipeline, organization folder if an Org Folder), assure it is the correct URL.

            People

            • Assignee:
              Unassigned
              Reporter:
              tbretz94 Tim Bretz
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: