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

          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

          markewaite, I think the solution can be to take the default value of the parameter set for the job, not the actual build parameter.

          Stanislav Bashkyrtsev added a comment - markewaite , I think the solution can be to take the default value of the parameter set for the job, not the actual build parameter.

          Mark Waite added a comment -

          OK, I'd be willing to evaluate a pull request from someone else, with automated tests, which attempts to expand the repository browser URL field.

          I'm not likely to implement that myself.

          Mark Waite added a comment - OK, I'd be willing to evaluate a pull request from someone else, with automated tests, which attempts to expand the repository browser URL field. I'm not likely to implement that myself.

          shaun barker added a comment -

          I think guess that the desire is to use the value of the parameterised property when it was used to run the job last - so that when you look in the historic runs view/details page you can click thru to git repo from there and see changes etc .. no? This way jenkins would have known the value at the time, and the issue isnt about passing in the value at the time the user elects to press the button.

          shaun barker added a comment - I think guess that the desire is to use the value of the parameterised property when it was used to run the job last - so that when you look in the historic runs view/details page you can click thru to git repo from there and see changes etc .. no? This way jenkins would have known the value at the time, and the issue isnt about passing in the value at the time the user elects to press the button.

          Alin Pana added a comment -

          Hello!

          I have the same problem. Does it have someone a workaround for this?

          Alin Pana added a comment - Hello! I have the same problem. Does it have someone a workaround for this?

          Mark Waite added a comment -

          No work around, and no work has been done to implement this.  I expect the implementation will be more complex than usual, since it will require extracting the parameter value from the job history based on the build number of the link being clicked.

          Mark Waite added a comment - No work around, and no work has been done to implement this.  I expect the implementation will be more complex than usual, since it will require extracting the parameter value from the job history based on the build number of the link being clicked.

          Alin Pana added a comment -

          markewaite Please let me know if I can help you somehow.

          Alin Pana added a comment - markewaite Please let me know if I can help you somehow.

          Mark Waite added a comment -

          qalinn if this enhancement is important to you, you could implement the enhancement (with tests) and submit it as a pull request. I won't implement this enhancement because I believe we should prefer multi-branch pipeline jobs for this type of activity, rather than using freestyle jobs with parameters.

          If you'd like to help the Jenkins project in general, there are many ways to help. Refer to "Jenkins needs you" for some ideas I collected for helping the Jenkins project.

          Mark Waite added a comment - qalinn if this enhancement is important to you, you could implement the enhancement (with tests) and submit it as a pull request. I won't implement this enhancement because I believe we should prefer multi-branch pipeline jobs for this type of activity, rather than using freestyle jobs with parameters. If you'd like to help the Jenkins project in general, there are many ways to help. Refer to " Jenkins needs you " for some ideas I collected for helping the Jenkins project.

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

              Created:
              Updated: