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

Existing variables not being substituted in Properties Content

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: envinject-plugin
    • Labels:
    • Environment:
      Jenkins: 2.83
      EnvInject API Plugin: 2.3
      Environment Injector Plugin: 2.1.4
    • Similar Issues:
    • Released As:
      2.1.6

      Description

      It looks like variables are not being resolved/substituted as they were previously in the "Properties Content" section of the EnvInjectJobProperty section of a job. In version 2.1.3 of the plugin, the steps below worked. In 2.1.4 it no longer works.

      Steps to Reproduce:

      1. Create a new job, simple/free-style is fine.
      2. Enable the Prepare an environment for the run job property.
      3. In the Properties Content section, enter the content:
        TEST_FILE=${WORKSPACE}/test.txt
      1. Save and run the job.
      2. View the environment variables of the build.

      Expected Result:

      I would expect the environment variable TEST_FILE to be equal to the value of the WORKSPACE environment variable with "/test.txt" append on to the end of it. For example, if WORKSPACE is equal to "/workspace" then the value of TEST_FILE should be "/workspace/test.txt". This was the behavior prior to the 2.1.4 release.

      Actual Result:

      The actual result is that TEST_FILE is literally equal to the value entered. For example, "${WORKSPACE}/test.txt". This behavior started in 2.1.4.

        Attachments

          Issue Links

            Activity

            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Oleg Nenashev
            Path:
            pom.xml
            http://jenkins-ci.org/commit/envinject-plugin/05fffd291109514321bfbeab0fd62454ebb74f88
            Log:
            Merge pull request #127 from oleg-nenashev/2.1.4-compat-notice

            Add compatibility notice for JENKINS-47364 and JENKINS-47370

            Compare: https://github.com/jenkinsci/envinject-plugin/compare/03a66052daa3...05fffd291109

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: pom.xml http://jenkins-ci.org/commit/envinject-plugin/05fffd291109514321bfbeab0fd62454ebb74f88 Log: Merge pull request #127 from oleg-nenashev/2.1.4-compat-notice Add compatibility notice for JENKINS-47364 and JENKINS-47370 Compare: https://github.com/jenkinsci/envinject-plugin/compare/03a66052daa3...05fffd291109
            Hide
            gmc_devel GMC Software Development B&R Corporate added a comment -

            Hi!

            We have a similar issue with parametrized builds; I.e. Job A triggers B and passes the parameter 'X=${X1}', but this variable X1 is unknown/not set. Job B receives (also for the previous release) 'X=${X1}' and has a envinject-step 'X1=${X}'. Up to EnvInject 2.1.3, the result of the variable substitution of X1 was an empty content (and this variable X1 was used in the batch-steps afterwards).

            Beginning with EnvInject 2.1.4 the passed literal content (${X1}) is passed from the job-paramter X to the "local" variable X1 of the triggered Job B.  After some tests, we have found a work-around for this case:

            • Add 'Prepare an environment for the run' in the job-configuration, but without any variable assignment
            • Set option 'Override Build Parameters'

            With this this option, the result of the substitution of X1 is an empty string/content like in the previous release. I have not made further tests, whether this work-around does solve only this (our) kind of variable-substitution issue or whether there are other side-effects ...

            Best regards from Salzburg,
            Markus

             

            Show
            gmc_devel GMC Software Development B&R Corporate added a comment - Hi! We have a similar issue with parametrized builds; I.e. Job A triggers B and passes the parameter 'X=${X1}', but this variable X1 is unknown/not set. Job B receives (also for the previous release) 'X=${X1}' and has a envinject-step 'X1=${X}'. Up to EnvInject 2.1.3, the result of the variable substitution of X1 was an empty content (and this variable X1 was used in the batch-steps afterwards). Beginning with EnvInject 2.1.4 the passed literal content (${X1}) is passed from the job-paramter X to the "local" variable X1 of the triggered Job B.  After some tests, we have found a work-around for this case: Add 'Prepare an environment for the run' in the job-configuration, but without any variable assignment Set option 'Override Build Parameters' With this this option, the result of the substitution of X1 is an empty string/content like in the previous release. I have not made further tests, whether this work-around does solve only this (our) kind of variable-substitution issue or whether there are other side-effects ... Best regards from Salzburg, Markus  
            Hide
            adovi_accenture arnaud dovi added a comment -

            If you are not going to touch this issue anymore this is serious problem here, as administrator It's impossible to communicate to the team the DO NOT UPDATE EnvInject I have to ban all jenkins domains in the host Linux configuration level to stop Jenkins updates

            My suggestion (only if you are not going to improve this fix causing regressions)

            • branch the 2.1.3 version to a newer plugin called "Environment Injector Plugin (Old compatibility version)"

            So we can stick to this version, because I believe we need Jenkins updates while we dont need EnvInject updates anymore and want it as it is working actually, the fix you published for it was not affecting us.

            Show
            adovi_accenture arnaud dovi added a comment - If you are not going to touch this issue anymore this is serious problem here, as administrator It's impossible to communicate to the team the DO NOT UPDATE EnvInject I have to ban all jenkins domains in the host Linux configuration level to stop Jenkins updates My suggestion (only if you are not going to improve this fix causing regressions) branch the 2.1.3 version to a newer plugin called "Environment Injector Plugin (Old compatibility version)" So we can stick to this version, because I believe we need Jenkins updates while we dont need EnvInject updates anymore and want it as it is working actually, the fix you published for it was not affecting us.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            Unfortunately I will not have time to work on EnvInject issues for a while. I decided to unassign all issues so that somebody can take them and finalize.

            Context: The plugin has been waiting for adoption for ~2 years. During all this time I was trying to keep this plugin afloat by reviewing the incoming pull requests, fixing defects and keeping the codebase up to date to simplify the handover. But I have not been using this plugin on my own so that such maintenance was a bit lame. I invite all active users to contribute to the plugin by taking ownership of this plugin and of EnvInject API. I am happy to provide any required knowledge transfers and do some assistance during the first months of maintenance

            Show
            oleg_nenashev Oleg Nenashev added a comment - Unfortunately I will not have time to work on EnvInject issues for a while. I decided to unassign all issues so that somebody can take them and finalize. Context: The plugin has been waiting for adoption for ~2 years. During all this time I was trying to keep this plugin afloat by reviewing the incoming pull requests, fixing defects and keeping the codebase up to date to simplify the handover. But I have not been using this plugin on my own so that such maintenance was a bit lame. I invite all active users to contribute to the plugin by taking ownership of this plugin and of EnvInject API. I am happy to provide any required knowledge transfers and do some assistance during the first months of maintenance
            Hide
            ickersep ickersep added a comment -

            This seems to be fixed in 2.1.6

            Show
            ickersep ickersep added a comment - This seems to be fixed in 2.1.6

              People

              • Assignee:
                Unassigned
                Reporter:
                krische Brian Krische
              • Votes:
                12 Vote for this issue
                Watchers:
                21 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: