Repository navigation
Parameterized repository name #1543
Description
What feature do you want to see added?
With gitSCM I can do:
gitSCM {
userRemoteConfigs {
userRemoteConfig {
credentialsId("github-token")
url('https://github.com/Owner/^${repo}.git')
name("origin")
refspec('+refs/pull/^${PR_NUMBER}/head:refs/remotes/origin/PR-^${PR_NUMBER}')
}
}
and dynamically load a repository based on the job parameters.
but trying similarly with github SCM:
github('Owner/^${repo}')
results in:
hudson.plugins.git.GitException: Command "git fetch --tags --force --progress --prune -- origin +refs/heads/PR-183:refs/remotes/origin/PR-183" returned status code 128:
stdout:
stderr: remote: Repository not found.
fatal: repository '[https://github.com/Owner/${repo}.git/](https://github.com/Owner/$%7Brepo%7D.git/)' not found
(The ^ is due to being Job DSL inside a Helm YAML file.)
The reason for the job parameter used in the repository name is this job acts as a special "hold open integration testing environment setup" mode that is triggered for any repository by a special URL put in a GitHub PR comment. So people can click the comment link and trigger this Jenkins job to do a stand-up of the integration environment and then hold it open (waiting for Jenkins input) until they click another link and push the Jenkins Job UI button to teardown the deployments.
Upstream changes
No response
Are you interested in contributing this feature?
No response
Activity
itsvshreyas commentedon Aug 24, 2026
Hi @gannett-ggreer , I have opened a PR to fix this issue. Could you please take a look into it? Thanks!
jglick commentedon Sep 18, 2026
I do not think this old misfeature in the
gitplugin should be copied. The stated use case can be addressed more simplywithGit(…) { sh 'git clone -b $BRANCH_FROM_BUILD_PARAM $REPO_FROM_BUILD_PARAM . && ./run.sh' }