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

TOOLNAME_HOME Variable Not Available For Use in Freestyle Build Step

    Details

    • Similar Issues:

      Description

      Summary

      Attempting to use the TOOLNAME_HOME variable within an Execute system Groovy script build step causes error due to no variable expansion.
      java.io.FileNotFoundException: /jenkins-home/workspace/FreeEnvVar/${TESTTOOL_HOME}/script.groovy (No such file or directory)

      Steps to reproduce

      1. Install custom build tool plugin and system groovy script plugin
      2. Create a custom build tool called "TestTool" which downloads a file from some URL
      3. Create a freestyle job
      4. In the freestyle job, select "Install custom tools" and a Tool which has a Tool Selection of "TestTool". Be sure to select the the "Convert #ToolName_HOME variables to the upper-case"
      5. In the build steps section of the freestyle job, add a step to "Execute System Groovy script" with the "Groovy Script File" option selected and the path to the groovy script file should be "TESTTOOL_HOME"
      6. Save the job

      Expect behavior

      When you run the job, the TESTTOOL_HOME variable is correctly explanded before the System Groovy Step evalutes the file location

      Actual behavior

      When you run the job, the TESTTOOL_HOME variable is not corretly expanded by the System Groovy Step, resulting in an error like this:

      FATAL: /jenkins-home/workspace/FreeEnvVar/${TESTTOOL_HOME}/script.groovy (No such file or directory)
      java.io.FileNotFoundException: /jenkins-home/workspace/FreeEnvVar/${TESTTOOL_HOME}/script.groovy (No such file or directory)
          at java.io.FileInputStream.open0(Native Method)
          at java.io.FileInputStream.open(FileInputStream.java:195)
          at java.io.FileInputStream.<init>(FileInputStream.java:138)
          at hudson.FilePath.read(FilePath.java:1754)
          at hudson.FilePath.readToString(FilePath.java:1855)
          at hudson.plugins.groovy.FileSystemScriptSource.getSecureGroovyScript(FileSystemScriptSource.java:31)
          at hudson.plugins.groovy.SystemGroovy.run(SystemGroovy.java:95)
          at hudson.plugins.groovy.SystemGroovy.perform(SystemGroovy.java:59)
          at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
          at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
          at hudson.model.Build$BuildExecution.build(Build.java:206)
          at hudson.model.Build$BuildExecution.doRun(Build.java:163)
          at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
          at hudson.model.Run.execute(Run.java:1728)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          at hudson.model.ResourceController.execute(ResourceController.java:98)
          at hudson.model.Executor.run(Executor.java:407)
      

        Attachments

          Issue Links

            Activity

            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            I believe this is a Groovy plugin issue. Custom Tools plugin contributes env vars in a common way,  I am not sure how it handles it

            Show
            oleg_nenashev Oleg Nenashev added a comment - I believe this is a Groovy plugin issue. Custom Tools plugin contributes env vars in a common way,  I am not sure how it handles it
            Hide
            ercanales Enrique Canales added a comment -

            I think you are correct here. I'll remove the custom_tools plugin specifically from the ticket.

            Show
            ercanales Enrique Canales added a comment - I think you are correct here. I'll remove the custom_tools plugin specifically from the ticket.
            Hide
            recampbell Ryan Campbell added a comment -

            Noting that variables contributed by envInject ARE properly expanded by the System Groovy Step. 

            Show
            recampbell Ryan Campbell added a comment - Noting that variables contributed by envInject ARE properly expanded by the System Groovy Step. 
            Hide
            recampbell Ryan Campbell added a comment - - edited

            Perhaps the evaluation is  incorrectly done in FileSystemScriptSource::getSecureGroovyScript(FilePath,AbstractBuild,TaskListener):

                public SecureGroovyScript getSecureGroovyScript(FilePath projectWorkspace, AbstractBuild<?, ?> build, TaskListener listener) throws IOException, InterruptedException {
                    EnvVars env = build.getEnvironment(listener);
                    String expandedScriptFile = env.expand(this.scriptFile);
                    String text = new FilePath(projectWorkspace, expandedScriptFile).readToString();
                    return new SecureGroovyScript(text, true, null).configuring(ApprovalContext.create()/* unused but just in case: */.withItem(build.getParent()));
                }
            

            After debugging this, we see that "env" does not contain an environment variable for the custom tool.

            Show
            recampbell Ryan Campbell added a comment - - edited Perhaps the evaluation is  incorrectly done in FileSystemScriptSource::getSecureGroovyScript(FilePath,AbstractBuild,TaskListener ): public SecureGroovyScript getSecureGroovyScript(FilePath projectWorkspace, AbstractBuild<?, ?> build, TaskListener listener) throws IOException, InterruptedException { EnvVars env = build.getEnvironment(listener); String expandedScriptFile = env.expand( this .scriptFile); String text = new FilePath(projectWorkspace, expandedScriptFile).readToString(); return new SecureGroovyScript(text, true , null ).configuring(ApprovalContext.create() /* unused but just in case : */ .withItem(build.getParent())); } After debugging this, we see that "env" does not contain an environment variable for the custom tool.
            Hide
            recampbell Ryan Campbell added a comment - - edited

            The problem may actually be in the Custom Build Tools plugin.

            The CustomToolInstallWrapper#setup(AbstractBuild,Launcher,BuildListener) returns a hudson.model.Environment, but it seems like these enviroment variables are not reflected in the EnvVars returned by build.getEnvironment(listener).

            So the CustomToolInstallWrapper is perhaps only affecting processes which are launched and not actually exposing environment variables to other evaluations like this one.

            In this case, it seems like the fix is for Custom tools plugin to extend the hudson.model.EnvironmentContributor to fix this problem.

            Show
            recampbell Ryan Campbell added a comment - - edited The problem may actually be in the Custom Build Tools plugin. The CustomToolInstallWrapper#setup(AbstractBuild,Launcher,BuildListener) returns a hudson.model.Environment, but it seems like these enviroment variables are not reflected in the EnvVars returned by build.getEnvironment(listener). So the CustomToolInstallWrapper is perhaps only affecting processes which are launched and not actually exposing environment variables to other evaluations like this one. In this case, it seems like the fix is for Custom tools plugin to extend the hudson.model.EnvironmentContributor to fix this problem.
            Hide
            recampbell Ryan Campbell added a comment -

            In, JENKINS-19892, Oleg says:

            Plugin exports ${toolName_HOME} or ${TOOLNAME_HOME} according to options. In the current state, shese variables are being exported to build steps based on remote launchers (execute shells, etc.). Steps like envInject or parameterizedTrigger (which don't invoke external process) have access to toolVersion only. I hope to fix this issue at some point; as a workaround you can write variable to file and then inject it to the environment using EnvInject build step.

            So I think this is exactly the issue – perhaps this bug report is a dupe of JENKINS-19892

            Show
            recampbell Ryan Campbell added a comment - In, JENKINS-19892 , Oleg says: Plugin exports ${toolName_HOME} or ${TOOLNAME_HOME} according to options. In the current state, shese variables are being exported to build steps based on remote launchers (execute shells, etc.). Steps like envInject or parameterizedTrigger (which don't invoke external process) have access to toolVersion only. I hope to fix this issue at some point; as a workaround you can write variable to file and then inject it to the environment using EnvInject build step. So I think this is exactly the issue – perhaps this bug report is a dupe of JENKINS-19892
            Hide
            ataylor Alex Taylor added a comment -

            I am pretty sure I fixed this issue with the new PR. If anyone has time to test it out for themselves locally that would be great

            Show
            ataylor Alex Taylor added a comment - I am pretty sure I fixed this issue with the new PR . If anyone has time to test it out for themselves locally that would be great
            Hide
            ataylor Alex Taylor added a comment -

            Anyone have time to review my PR and give the "all good"?

            Once I can get someone else who says this works then I will work on getting a new release

            Show
            ataylor Alex Taylor added a comment - Anyone have time to review my PR and give the "all good"? Once I can get someone else who says this works then I will work on getting a new release

              People

              • Assignee:
                ataylor Alex Taylor
                Reporter:
                ercanales Enrique Canales
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated: