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

Parameters not expanded in the Repository browser URL field

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None

      I have a parametrized job where the parameter value is being replaced as expected in the git Repository URL field. However if I use the same variable in the Repository browser URL, the parameter is not expanded on the https://my-jenkins-server/job/my-job/job-num/ pages build info pages.

      On that page, the repository links are showing up as "https://my-git-server/${REPO}" instead of have "${REPO}" replaced with the parameter passed to the job.

      The job is using the correct repo otherwise, so does look like the ${REPO} replacement is working for the Repository URL field.

      I'm using the gitlab version 6.8 as the repository browser.

          [JENKINS-29842] Parameters not expanded in the Repository browser URL field

          pwan created issue -
          pwan made changes -
          Description Original: I have a parametrized job where the parameter value is being replaced as expected in the git Repository URL field. However if I use the same variable in the Repository browser URL, the parameter is not expanded on the https://my-jenkins-server/job/my-job/job-num/ pages build info pages.

          On that page, the repository links are showing up as "https://my-git-server/\${REPO}" instead of have "\${REPO}" replaced with the parameter passed to the job.

          The job is using the correct repo otherwise, so does look like the \${REPO} replacement is working for the Repository URL field.

          New: I have a parametrized job where the parameter value is being replaced as expected in the git Repository URL field. However if I use the same variable in the Repository browser URL, the parameter is not expanded on the https://my-jenkins-server/job/my-job/job-num/ pages build info pages.

          On that page, the repository links are showing up as "https://my-git-server/$\{REPO}" instead of have "$\{REPO}" replaced with the parameter passed to the job.

          The job is using the correct repo otherwise, so does look like the $\{REPO} replacement is working for the Repository URL field.

          pwan made changes -
          Description Original: I have a parametrized job where the parameter value is being replaced as expected in the git Repository URL field. However if I use the same variable in the Repository browser URL, the parameter is not expanded on the https://my-jenkins-server/job/my-job/job-num/ pages build info pages.

          On that page, the repository links are showing up as "https://my-git-server/$\{REPO}" instead of have "$\{REPO}" replaced with the parameter passed to the job.

          The job is using the correct repo otherwise, so does look like the $\{REPO} replacement is working for the Repository URL field.

          New: I have a parametrized job where the parameter value is being replaced as expected in the git Repository URL field. However if I use the same variable in the Repository browser URL, the parameter is not expanded on the https://my-jenkins-server/job/my-job/job-num/ pages build info pages.

          On that page, the repository links are showing up as "https://my-git-server/$\{REPO}" instead of have "$\{REPO}" replaced with the parameter passed to the job.

          The job is using the correct repo otherwise, so does look like the $\{REPO} replacement is working for the Repository URL field.

          I'm using the gitlab

          pwan made changes -
          Description Original: I have a parametrized job where the parameter value is being replaced as expected in the git Repository URL field. However if I use the same variable in the Repository browser URL, the parameter is not expanded on the https://my-jenkins-server/job/my-job/job-num/ pages build info pages.

          On that page, the repository links are showing up as "https://my-git-server/$\{REPO}" instead of have "$\{REPO}" replaced with the parameter passed to the job.

          The job is using the correct repo otherwise, so does look like the $\{REPO} replacement is working for the Repository URL field.

          I'm using the gitlab

          New: I have a parametrized job where the parameter value is being replaced as expected in the git Repository URL field. However if I use the same variable in the Repository browser URL, the parameter is not expanded on the https://my-jenkins-server/job/my-job/job-num/ pages build info pages.

          On that page, the repository links are showing up as "https://my-git-server/$\{REPO}" instead of have "$\{REPO}" replaced with the parameter passed to the job.

          The job is using the correct repo otherwise, so does look like the $\{REPO} replacement is working for the Repository URL field.

          I'm using the gitlab repository setting

          pwan made changes -
          Description Original: I have a parametrized job where the parameter value is being replaced as expected in the git Repository URL field. However if I use the same variable in the Repository browser URL, the parameter is not expanded on the https://my-jenkins-server/job/my-job/job-num/ pages build info pages.

          On that page, the repository links are showing up as "https://my-git-server/$\{REPO}" instead of have "$\{REPO}" replaced with the parameter passed to the job.

          The job is using the correct repo otherwise, so does look like the $\{REPO} replacement is working for the Repository URL field.

          I'm using the gitlab repository setting

          New: I have a parametrized job where the parameter value is being replaced as expected in the git Repository URL field. However if I use the same variable in the Repository browser URL, the parameter is not expanded on the https://my-jenkins-server/job/my-job/job-num/ pages build info pages.

          On that page, the repository links are showing up as "https://my-git-server/$\{REPO}" instead of have "$\{REPO}" replaced with the parameter passed to the job.

          The job is using the correct repo otherwise, so does look like the $\{REPO} replacement is working for the Repository URL field.

          I'm using the gitlab

          pwan made changes -
          Description Original: I have a parametrized job where the parameter value is being replaced as expected in the git Repository URL field. However if I use the same variable in the Repository browser URL, the parameter is not expanded on the https://my-jenkins-server/job/my-job/job-num/ pages build info pages.

          On that page, the repository links are showing up as "https://my-git-server/$\{REPO}" instead of have "$\{REPO}" replaced with the parameter passed to the job.

          The job is using the correct repo otherwise, so does look like the $\{REPO} replacement is working for the Repository URL field.

          I'm using the gitlab

          New: I have a parametrized job where the parameter value is being replaced as expected in the git Repository URL field. However if I use the same variable in the Repository browser URL, the parameter is not expanded on the https://my-jenkins-server/job/my-job/job-num/ pages build info pages.

          On that page, the repository links are showing up as "https://my-git-server/$\{REPO}" instead of have "$\{REPO}" replaced with the parameter passed to the job.

          The job is using the correct repo otherwise, so does look like the $\{REPO} replacement is working for the Repository URL field.

          I'm using the gitlab version 6.8 as the repository browser.

          Mark Waite added a comment - - edited

          I'm not sure what you're expecting parameter expansion to do in that case.

          Should it be replaced with the default value (as is done for polling with a parameterized repository name)?

          Should it be replaced with the value used in the last job?

          Should it be replaced with the value used in the last successful job?

          Mark Waite added a comment - - edited I'm not sure what you're expecting parameter expansion to do in that case. Should it be replaced with the default value (as is done for polling with a parameterized repository name)? Should it be replaced with the value used in the last job? Should it be replaced with the value used in the last successful job?

          Mark Anstice added a comment -

          Unfortunately I have also fallen foul of this issue. I think my situation is the same as pwan describes in that I have a parametrized job where I pass in the name of the Git repository as the GIT_REPO parameter, the Git Repository Url is git@<MyGitServer>:/opt/git/$GIT_REPO and the job successfully expands the value of the Git Url and checks out the correct repository.

          Using gitweb as the repository browser I want to pass the same parameter into the URL e.g. http://<MyGitServer>/gitweb/?p=$GIT_REPO. However GIT_REPO does not get expanded.

          markewaite - I'm not sure which case you are referring to, I don't see how any replacement is needed, surely expansion is what we need?

          Mark Anstice added a comment - Unfortunately I have also fallen foul of this issue. I think my situation is the same as pwan describes in that I have a parametrized job where I pass in the name of the Git repository as the GIT_REPO parameter, the Git Repository Url is git@<MyGitServer>:/opt/git/$GIT_REPO and the job successfully expands the value of the Git Url and checks out the correct repository. Using gitweb as the repository browser I want to pass the same parameter into the URL e.g. http://<MyGitServer>/gitweb/?p=$GIT_REPO. However GIT_REPO does not get expanded. markewaite - I'm not sure which case you are referring to, I don't see how any replacement is needed, surely expansion is what we need?

          Mark Waite added a comment -

          Sorry that my question was unclear. I've edited it to ask what parameter expansion is expected to do in the case you're describing. If the repository name is a parameter, then what value should be used when a user clicks a link which requires parameter expansion?

          Since parameters are not known until the job is run, and parameters can change from one run to the next run, I don't know how the system can correctly resolve the parameter embedded in the repository browser URL in the way users would expect. For example, if I am looking at list of changes that created job 5, wouldn't the user expect that the parameter expansion in that case would use the value that had been assigned at the start of job 5? Then, if the user was looking at the changes created during job 7, they would expect the parameter value would evaluate to the value assigned at the start of job 7?

          I'm not aware of a facility in Jenkins to extract the value of parameters in a specific job number. It probably exists, but I'm not aware of it. I'm willing to evaluate a pull request from someone else which implements something like that, but it seems confusing (to me) to have a single job which freely switches between repositories. The recent changes list will be trying to show differences between completely different repositories from one build to the next. The polling will only detect changes in the repository named with the default parameter value.

          Mark Waite added a comment - Sorry that my question was unclear. I've edited it to ask what parameter expansion is expected to do in the case you're describing. If the repository name is a parameter, then what value should be used when a user clicks a link which requires parameter expansion? Since parameters are not known until the job is run, and parameters can change from one run to the next run, I don't know how the system can correctly resolve the parameter embedded in the repository browser URL in the way users would expect. For example, if I am looking at list of changes that created job 5, wouldn't the user expect that the parameter expansion in that case would use the value that had been assigned at the start of job 5? Then, if the user was looking at the changes created during job 7, they would expect the parameter value would evaluate to the value assigned at the start of job 7? I'm not aware of a facility in Jenkins to extract the value of parameters in a specific job number. It probably exists, but I'm not aware of it. I'm willing to evaluate a pull request from someone else which implements something like that, but it seems confusing (to me) to have a single job which freely switches between repositories. The recent changes list will be trying to show differences between completely different repositories from one build to the next. The polling will only detect changes in the repository named with the default parameter value.

          Tidhar Klein Orbach added a comment - - edited

          I have the same issue, my repository URL field is:

          ${STASH_PROD_URL}/projects/${GIT_PROJECT}/repos/${GIT_REPOSITORY}/
          

          The parameters / tokens do not get parsed to their value (STASH_PROD_URL is a global Jenkins parameter, the 2 other are job parameters), so the resulted url consist the ${} tokens.
          my environment is:
          core 1.565.3
          GIT client plugin 1.11.0
          GIT plugin 2.2.7
          Git server plugin 1.6
          Token Macro Plugin 1.10
          Parameterized Trigger plugin 2.20

          Tidhar Klein Orbach added a comment - - edited I have the same issue, my repository URL field is: ${STASH_PROD_URL}/projects/${GIT_PROJECT}/repos/${GIT_REPOSITORY}/ The parameters / tokens do not get parsed to their value (STASH_PROD_URL is a global Jenkins parameter, the 2 other are job parameters), so the resulted url consist the ${} tokens. my environment is: core 1.565.3 GIT client plugin 1.11.0 GIT plugin 2.2.7 Git server plugin 1.6 Token Macro Plugin 1.10 Parameterized Trigger plugin 2.20

            Unassigned Unassigned
            pwan pwan
            Votes:
            6 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: