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

TOOL_HOME doesn't work in PATH

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      According to the changelog, it looks like TOOL_HOME should work, but when i use it in the export paths, it fails:

      ERROR: Can't resolve all variables in EXPORTED_PATHS string. Final state: ${TOOL_HOME}/bin

      How do i reference the tool home directory to update the path?

        Attachments

          Issue Links

            Activity

            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            In exported paths you can use relative paths. BTW, it is an issue for exported variables

            Change was a quite different: it allows to convert tool homes to uppercase

            Show
            oleg_nenashev Oleg Nenashev added a comment - In exported paths you can use relative paths. BTW, it is an issue for exported variables Change was a quite different: it allows to convert tool homes to uppercase
            Hide
            jdamick Jeffrey Damick added a comment -

            Is there an env variable to use for the tool install path? i actually need it for a different reason than shown above.

            Show
            jdamick Jeffrey Damick added a comment - Is there an env variable to use for the tool install path? i actually need it for a different reason than shown above.
            Hide
            oleg_nenashev Oleg Nenashev added a comment - - edited

            Do you mean installation path in custom-tool config or variable for build steps?

            First case:

            • In "installation path" you can use node/global variables and the build environment, which have been before wrappers (external variables, build parameters, SCM info, etc.)

            Second case:

            • 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.
            Show
            oleg_nenashev Oleg Nenashev added a comment - - edited Do you mean installation path in custom-tool config or variable for build steps? First case: In "installation path" you can use node/global variables and the build environment, which have been before wrappers (external variables, build parameters, SCM info, etc.) Second case: 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.
            Hide
            per_olausson Per Olausson added a comment - - edited

            Hi, just some feedback on this.. We wasted some cycles due to this very issue. Worth pointing out is that dashes ( - ) and dots ( . ) are not allowed as environment variables when using bash, so when someone defines a custom tool eg. PYTHON-3.4.0 then the variable the custom tools plugin exports isn't actually usable.

            It would make sense if you guys changed the tool to translate dashes ( - ) and dots ( . ) to a valid character, ie. underscore ( _ ).

            Possibly some of your users are having this problem, not realising that it is because environment variables are invalid from a shell perspective.

            Secondly, renaming custom tools is a bit dangerous, since if a project has one of these tools used, it won't find it and just pick the first tool ever defined, whenever a project configuration is updated...which can be some time after the actual custom tools definition changed. Not sure how easy that is to fix.

            Show
            per_olausson Per Olausson added a comment - - edited Hi, just some feedback on this.. We wasted some cycles due to this very issue. Worth pointing out is that dashes ( - ) and dots ( . ) are not allowed as environment variables when using bash, so when someone defines a custom tool eg. PYTHON-3.4.0 then the variable the custom tools plugin exports isn't actually usable. It would make sense if you guys changed the tool to translate dashes ( - ) and dots ( . ) to a valid character, ie. underscore ( _ ). Possibly some of your users are having this problem, not realising that it is because environment variables are invalid from a shell perspective. Secondly, renaming custom tools is a bit dangerous, since if a project has one of these tools used, it won't find it and just pick the first tool ever defined, whenever a project configuration is updated...which can be some time after the actual custom tools definition changed. Not sure how easy that is to fix.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            @Per
            Sorry for missing your comments due to the business trip.
            I'll revise the plugin and improve the validation/escaping

            The initial issue should be fixes as well.

            Show
            oleg_nenashev Oleg Nenashev added a comment - @Per Sorry for missing your comments due to the business trip. I'll revise the plugin and improve the validation/escaping The initial issue should be fixes as well.
            Hide
            tbridges Tony Bridges added a comment -

            @Oleg Any update on this ?   It sounds like you were working on the fix almost 3 years ago ?

            We get routinely hammered on dashes and dots in tool names, all the more so because it's a natural fit for versioned tools.  maven-3.3.3, for example.  Everyone knows not to do it, but someone always forgets, and then cycles are lost figuring out why the tooling isn't working.

            thanks.

            Show
            tbridges Tony Bridges added a comment - @Oleg Any update on this ?   It sounds like you were working on the fix almost 3 years ago ? We get routinely hammered on dashes and dots in tool names, all the more so because it's a natural fit for versioned tools.  maven-3.3.3, for example.  Everyone knows not to do it, but someone always forgets, and then cycles are lost figuring out why the tooling isn't working. thanks.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            I definitely had a plan to work on the issue, but likely it slipped down on my priority list. The issue is in the "Open" state, so effectively there is no ongoing work.

            I still maintain the Custom Tools plugin during my spare time (e.g. there is a fix for JENKINS-46141 in progress), but obviously I cannot dedicate enough time to it due to other community commitments. In the case of JENKINS-19892 to review pull requests from others.

            I will remove the assignee to make it more explicit

            Show
            oleg_nenashev Oleg Nenashev added a comment - I definitely had a plan to work on the issue, but likely it slipped down on my priority list. The issue is in the "Open" state, so effectively there is no ongoing work. I still maintain the Custom Tools plugin during my spare time (e.g. there is a fix for JENKINS-46141 in progress), but obviously I cannot dedicate enough time to it due to other community commitments. In the case of JENKINS-19892 to review pull requests from others. I will remove the assignee to make it more explicit
            Hide
            ataylor Alex Taylor added a comment -

            This should be fixed with the update in https://issues.jenkins-ci.org/browse/JENKINS-53146

            Show
            ataylor Alex Taylor added a comment - This should be fixed with the update in https://issues.jenkins-ci.org/browse/JENKINS-53146

              People

              Assignee:
              ataylor Alex Taylor
              Reporter:
              jdamick Jeffrey Damick
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated: