Thanks for the report. It appears that 2.2.5 was evaluating the ${TargetUrl} environment variable correctly, and 2.2.6 is not doing that any longer.

A change was introduced in 2.2.5 (change1 and change2) which broadened the evaluation of environment variables in order to fix JENKINS-22009. It seemed to be too broad and resulted in JENKINS-24467 and JENKINS-24516. A change was merged in 2.2.6 which narrowed the scope of the evaluation of environment variables, trying to bring it more into line with the evaluation that happened in 2.2.4 and prior.

Was the use case you're using working with plugin versions prior to 2.2.5?

I'm not clear how to duplicate the bug. I need to understand where you're referencing ${TargetUrl} in the job definition.

Could you either post the job configuration file (config.xml) to the bug report, or mail it separately to me?

Hi Mark
I can't say if it would work prior 2.2.5, because I didn't use this job setup before as i can remember.
Attached the config.xml of the job.
TargetUrl is a job parameter of 3 with git url's I use. This is referenced for the fetch and then at the end for the push.
Just to explain, the job fetches a repo from github (origin), my local gitlab mirror (target) and my gitlab mirror/fork from the origin (target2) and then I push the branch to target and target2 with git publisher to keep my mirrors (target/target2) in sync with the origin.

To duplicate the bug, I think you could replace the default values of the origin parameters with some of your repos and maybe remove the target2 overall in the job for simplicity. Also just remove the "Docker plugin" stuff if you just want to use any other slave. The EnvInject can also be removed if you set the branch name without a variable.
The result should be a job with just 2 or 3 repos in the SCM config and 1 or 2 push in the git publisher config.

Nothing to do with this issue, but just a side question, as you see in the job, for such a simple (and in my eyes common job) i have to use EnvInject plugin to get the Branch name without the leading "origin" to use it in the git publisher for push. Because if I would directly use the GIT_BRANCH variable I get an error. I found many different approaches around how to handle that... but wouldn't it be easy to provide a GIT_BRANCH_NAME without the leading "origin" directly by the git plugin? I think would solve many ugly hacks out there

Thanks. I can duplicate the problem with a sample job. The steps I took:

1. Define a free-style project
2. Define a string parameter TARGET_URL for the project, default to ssh://mwaite@mark-pc1/var/lib/git/mwaite/JENKINS-12316.git
3. Use git as the SCM for the freestyle project
4. Configure git repo to use ${TARGET_URL} as repository URL
5. Run the job, confirm it succeeds, confirm log does not contain literal string TARGET_URL, and does contain the value of the parameter TARGET_URL
6. Add git publisher post build action to push the master branch
7. Run the job, confirm it now includes ${TARGET_URL} in the console log for git push (and only for git push)

Just had a quick look at this and I don't think it's related to JENKINS-24467 - mostly as the code changed there shouldn't run during the build, only at poll time.

In trying to repo this, I don't think it's due to expansion issue either, rather git credentials one.

2.2.5:

+ echo GIT_BRANCH_NAME=master
[EnvInject] - Script executed successfully.
[EnvInject] - Injecting environment variables from a build step.
[EnvInject] - Injecting as environment variables the properties file path 'environments.properties'
[EnvInject] - Variables injected successfully.
Pushing HEAD to branch master at repo gitrepo
 > git config --get remote.gitrepo.url # timeout=10
 > git push git@xxx:xxx/spaff.git HEAD:master
Started calculate disk usage of build
Finished Calculation of disk usage of build in 0 seconds
Started calculate disk usage of workspace
Finished Calculation of disk usage of workspace in 0 seconds
Finished: SUCCESS

2.2.6

+ echo GIT_BRANCH_NAME=master
[EnvInject] - Script executed successfully.
[EnvInject] - Injecting environment variables from a build step.
[EnvInject] - Injecting as environment variables the properties file path 'environments.properties'
[EnvInject] - Variables injected successfully.
Pushing HEAD to branch master at repo gitrepo
 > git push ${giturl} HEAD:master
Started calculate disk usage of build
Finished Calculation of disk usage of build in 0 seconds
Started calculate disk usage of workspace
Finished Calculation of disk usage of workspace in 0 seconds
Finished: SUCCESS

I also added a build step to change a file during the build and this was successfully pushed using 2.2.6. So yes, in the log the env_var is not expanded but I don't think this it the cause of the issue.

Config.xml (3k one, I should have used a different name) I used is attached, it's a simplified version of the one Thomas provided. This was tested using LTS 1.565.2.

I think the repo you have Mark is a something different.