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

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

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.

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.

@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.

@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.

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

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