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.

I Think Rob is right.
It's ugly that the env_var is not expanded in the log, but the error is "Permission denied".
And I miss the following two lines in the failing log which are in the success log before the real push try:

> git config --get remote.target.url # timeout=10
using GIT_SSH to set credentials Jenkins Key (used to access git.dihei.ch and github/spali)

I'm not as persuaded that it is authentication related, since there were no significant authentication related changes in the transition from git plugin 2.2.5 to 2.2.6.

There were updates to newer versions of the dependencies so that the credentials dependencies now depend on the most recently released versions of the credentials plugins and so that the plugin now depends on the most recent version of the git client plugin.

Several new credentials tests were added in git client plugin 1.10.2, but no significant authentication related changes in the transition from git client plugin 1.10.1 to 1.10.2. Have you been able to make local authentication changes which resolved the issue, or are you still stuck having to run plugin 2.2.5?

I'm still stuck on 2.2.5.
You are more expert than me, but because of the error message, I didn't try anything else, because the error states clearly to me that it's a permission problem.
The error for unknown host or not a valid url, when the var is not expanded is usually different.
I will check if I find time tomorrow to test it with a fixed value instead of an env variable.

Hi Mark
You were right. I stripped down the config as much as possible.
Create the job:
1. add parameter TargetUrl with repo url of a target.
2. in the scm section add an origin repo with any url directly put in and set credentials. name it origin
3. create a second repo with ${TargetUrl} and name it target
4. put "master" in branch to build
5. add git publisher to "target" repo branch master.

so the only dynamic parameter is the TargetUrl used in scm section for the second repo. I even removed EnvInject plugin, so this doesn't make any difference. You don't need this plugin to reproduce it.
The described build fails. But as soon as I replaced the ${TargetUrl} in the repo url field, it works.

So I assume, the permission error is just because it does not expand the TargetUrl env var (as you already told) and then it will try to push to the origin repo instead of the target. And I don't have the permissions there.
Due the fact it works during the fetch, it seems to be, that just git publisher does not resolve the env var during the push operation.
Not sure whats responsible usually to resolve the env vars, the plugin or if it is usually done just by the shell. But it seems to be that the shell does resolve it to an empty string (that's why git try to push to the origin).

Hope this helps to identify the root cause.

spali thanks very much for investigating! I'm still a little surprised that you successfully found a feature (environment expansion in Git publisher) that I think may have existed for only one version of the plugin. I'll need to do further experimenting with older versions of the plugin to see how it behaved prior to the changes for JENKINS-22009. I'll keep this bug report updated as I learn more.

I just rolled back to 2.2.4 because of this issue. It is confirmed working in 2.2.4.

Code changed in jenkins
User: Mark Waite
Path:
src/test/java/hudson/plugins/git/GitPublisherTest.java
http://jenkins-ci.org/commit/git-plugin/55b0fd8404dec9b10bcfe52865e93fdc9845c836
Log:
Add tests of GitPublisher honoring env values

Attempting to duplicate JENKINS-24786 from an automated test. Does not
duplicate the bug. Shows that GitPublisher honors some environment
variables.

Hey there Mark,
Any news on this issue? Today I updated to the latest 2.3 version..i was forced to rollback once again due to this issue :/

One thing I noted is that the GitPublisher only fails to expand a variable that is used in the Repository Url.
If you use it on any other field, such as GitTag name or something similar, everything works as expected.

Jenkins Core: 1.580.2
Git Plugin version: 2.3.x

I have hit a wall on the fix. My attempts to find a way to retain the other fixes included in 2.2.6 and fix this bug have failed. I'd love to have other eyes on the code, or alternative ways to implement the 2.2.6 fix which introduced the problem.

Hi Mark,

I also ran into the issue and had a look into the code. I try to summarize what I already found out - I hope this helps:

As the fetch is working I focused on analyzing the differences between the fetch and the push. As far as I understood the code the GitSCM holds the remote repository without expanded environment variables and expands them right before the fetch (https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L915). This step is is missing in the GitPublisher where the specified remote repository is retrieved from the gitSCM (https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitPublisher.java#L318). As this issue is urgent for our production I already started to prepare a test and fix for this issue. My naive approach would be simply do the same thing as GitSCM.getParamExpandedRepos() does right where the push command is created and executed. But as you wrote that you hit a wall here I'm a bit unconfident. Could you please share your concerns? I would need some more days to prepare a fix for a pull request but so far my first tests looked promising.

goddi Your approach sounds promising. I hit a wall when I couldn't construct a set of tests which gave me enough confidence that I'd solved the problem without critically damaging something else.

Since you're a directly involved user, you'll be able to test drive your changes in your own environment. A pull request from you will then allow me and/or Nicolas (or others) to review your changes in depth.

Created pull request 283 containing fix and tests. The updated git-plugin runs in our production jenkins without issues. Could you please review and provide feedback?

Code changed in jenkins
User: Daniel Figus
Path:
src/main/java/hudson/plugins/git/GitPublisher.java
src/main/java/hudson/plugins/git/GitSCM.java
src/test/java/hudson/plugins/git/GitPublisherTest.java
http://jenkins-ci.org/commit/git-plugin/f841caf3c2483532aad9feb20d2f3fac9722a878
Log:
JENKINS-24786 Environment variables are not expanded in git publisher

Fix: Git publisher fails if remote repository configuration contains
environment variables

The change from goddi has been rebased into the git plugin main line and will be available in git plugin 2.3.3 and later.