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

Since 2.2.6, environment variables are not expanded in git publisher

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
    • Environment:
      Jenkins: 1.580
      Git Plugin 2.2.6 (before update 2.2.5)
      All plugins up to date (21. September)
    • Similar Issues:

      Description

      Since 2.2.6 ssh credentials on git push seems to have a problem.
      When i revert back to 2.2.5 everything works as expected.
      I'm using jenkins credential with a ssh key.
      Don't know if that has something to say, but I'm using env var's to set the git url, and in the failing log it's not resolved. But I guess the error prints it before the resolution, because the connection itself seems to work, just not the authentication.
      I attached a log success.txt (with version 2.2.5) and a failing.txt (version 2.2.6). The only difference is that i reverted the plugin to 2.2.5 and everything worked again.
      let me know if you need more information. But maybe so find the problem due the recent changes.

        Attachments

        1. config.xml
          3 kB
        2. config.xml
          5 kB
        3. failing.txt
          5 kB
        4. success.txt
          4 kB

          Issue Links

            Activity

            spali Thomas Spalinger created issue -
            Hide
            markewaite Mark Waite added a comment - - edited

            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?

            Show
            markewaite Mark Waite added a comment - - edited 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?
            markewaite Mark Waite made changes -
            Field Original Value New Value
            Assignee Nicolas De Loof [ ndeloof ] Mark Waite [ markewaite ]
            Hide
            markewaite Mark Waite added a comment -

            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?

            Show
            markewaite Mark Waite added a comment - 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 ?
            markewaite Mark Waite made changes -
            Summary Since 2.2.6 ssh credentials on git push seems to have a problem. Since 2.2.6, environment variables are noto expanded in git publisher
            markewaite Mark Waite made changes -
            Summary Since 2.2.6, environment variables are noto expanded in git publisher Since 2.2.6, environment variables are not expanded in git publisher
            Hide
            spali Thomas Spalinger added a comment -

            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

            Show
            spali Thomas Spalinger added a comment - 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
            spali Thomas Spalinger made changes -
            Attachment config.xml [ 26908 ]
            Hide
            markewaite Mark Waite added a comment - - edited

            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)
            Show
            markewaite Mark Waite added a comment - - edited Thanks. I can duplicate the problem with a sample job. The steps I took: Define a free-style project Define a string parameter TARGET_URL for the project, default to ssh://mwaite@mark-pc1/var/lib/git/mwaite/JENKINS-12316.git Use git as the SCM for the freestyle project Configure git repo to use ${TARGET_URL} as repository URL 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 Add git publisher post build action to push the master branch Run the job, confirm it now includes ${TARGET_URL} in the console log for git push (and only for git push)
            Hide
            langers2k Rob Langley added a comment - - edited

            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.

            Show
            langers2k Rob Langley added a comment - - edited 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.
            langers2k Rob Langley made changes -
            Attachment config.xml [ 26909 ]
            Hide
            spali Thomas Spalinger added a comment -

            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)
            Show
            spali Thomas Spalinger added a comment - 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)
            Hide
            markewaite Mark Waite added a comment -

            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?

            Show
            markewaite Mark Waite added a comment - 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?
            Hide
            spali Thomas Spalinger added a comment -

            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.

            Show
            spali Thomas Spalinger added a comment - 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.
            Hide
            spali Thomas Spalinger added a comment -

            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.

            Show
            spali Thomas Spalinger added a comment - 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.
            Hide
            markewaite Mark Waite added a comment -

            Thomas Spalinger 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.

            Show
            markewaite Mark Waite added a comment - Thomas Spalinger 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.
            markewaite Mark Waite made changes -
            Link This issue is duplicated by JENKINS-24879 [ JENKINS-24879 ]
            Hide
            calexandre Carlos Alexandre added a comment -

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

            Show
            calexandre Carlos Alexandre added a comment - I just rolled back to 2.2.4 because of this issue. It is confirmed working in 2.2.4.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Mark Waite
            Path:
            src/test/java/hudson/plugins/git/GitPublisherTest.java
            http://jenkins-ci.org/commit/git-plugin/0814b694072509c3a3f49be33805cdb97075eba2
            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/test/java/hudson/plugins/git/GitPublisherTest.java http://jenkins-ci.org/commit/git-plugin/0814b694072509c3a3f49be33805cdb97075eba2 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.
            markewaite Mark Waite made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            integer Kanstantsin Shautsou made changes -
            Labels git-publisher
            Hide
            calexandre Carlos Alexandre added a comment - - edited

            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

            Show
            calexandre Carlos Alexandre added a comment - - edited 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
            Hide
            markewaite Mark Waite added a comment -

            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.

            Show
            markewaite Mark Waite added a comment - 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.
            Hide
            goddi Daniel Figus added a comment -

            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.

            Show
            goddi Daniel Figus added a comment - 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.
            Hide
            markewaite Mark Waite added a comment -

            Daniel Figus 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.

            Show
            markewaite Mark Waite added a comment - Daniel Figus 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.
            Hide
            goddi Daniel Figus added a comment -

            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?

            Show
            goddi Daniel Figus added a comment - 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?
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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
            Hide
            markewaite Mark Waite added a comment -

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

            Show
            markewaite Mark Waite added a comment - The change from Daniel Figus has been rebased into the git plugin main line and will be available in git plugin 2.3.3 and later.
            markewaite Mark Waite made changes -
            Status In Progress [ 3 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 158012 ] JNJira + In-Review [ 195844 ]
            markewaite Mark Waite made changes -
            Link This issue is related to JENKINS-49834 [ JENKINS-49834 ]

              People

              • Assignee:
                markewaite Mark Waite
                Reporter:
                spali Thomas Spalinger
              • Votes:
                3 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: