Relevance of specifying Tool Locations in Jenkins Node Configuration

12,639

Solution 1

In Global Configuration, you can configure different tools, such as Maven, JDK, Ant, etc. When you do that, you also provide an installation method (usually an automatic online installer).

Now, on the Job Configuration, when you configure a buildstep using one of the tools, for example Invoke Ant, you will see a drop down. The first option is Default, the next is whatever tool installations that you've configured in Global Configuration.

If you choose Default it will use whatever is already installed on the system by simply executing a command like java, ant, or mvn. Obviously, if those commands are not in the path, it will fail. If you choose one of the configured options, Jenkins will install it to the system (if not already done), and use that particular version (as opposed to the one you have under path).

This installation will happen on both the master and the slave nodes. If you do not want to use this automatic installation on a particular node, you can manually specify the location of the particular tool in the screenshot you provided.

The above is only useful if in your Job Configuration, you are selecting a specific version of the tool, other than Default, because as already explained: Default will use whatever is already installed on the system (not by Jenkins).

Solution 2

To answer your queries:

So how exactly does specifying Tool Locations help?

Well, not really i would say. It's meant to specify your custom installation directory path for any program that's already setup in your global config page in a different location. If you have configured mvn 2.0 in global settings but wish to use mvn 3.0 on this specific node, then you can use Tool Locations. However, it will work only if the path to the executable is already present in the PATH env variable of the user with which the slave process is running.

Is it just to help users see the tool paths when they visit Jenkins node configuration site?

Well, yes, you can say that. I am saying so because whenever you specify a custom path, it generally isn't in the PATH of the user with which the process is running. That's true in most of the cases because such binaries don't run independently. They need other dependent modules to work properly otherwise simply dropping a binary in one of the directories that's already present in the PATH would have sufficed. So, it's safe to say that you explicitly have to add the path to executable in PATH to make it work.

If you have noticed the Help (?) section in the Tool Locations, even that doesn't sound very excited about using this feature :P It says: You can specify the location of certain tools on this node, overriding the global configuration. (You may prefer to use automatic tool installers instead, removing the need to configure each node separately.)

Share:
12,639

Related videos on Youtube

Indrajeet
Author by

Indrajeet

Updated on September 17, 2022

Comments

  • Indrajeet
    Indrajeet over 1 year

    What does specifying tools under "Tool Locations" in Jenkins Node configuration, exactly do? enter image description here

    I wanted to run a mvn command in free style project. I specified the Maven tool and its home under "Tool Locations" and that didn't help. The job failed for not being able to find mvn. I followed this solution and modified the PATH variable to include maven path. That did the trick.

    So how exactly does specifying Tool Locations help? Is it just to help users see the tool paths when they visit Jenkins node configuration site?

  • Indrajeet
    Indrajeet over 9 years
    You say that, choosing one of the configured options, prompts Jenkins to install it to the system and use it. Does that mean that I don't have to explicitly check if the command is in the path. Will Jenkins be responsible to put it in the path?
  • Slav
    Slav over 9 years
    Yes, Jenkins will install it to special Jenkins location, usually under $JENKINS_HOME/tools. It doesn't need it in path, cause it will invoke it directly with the full path to that location. Do realize that this is only for Jenkins specific implementations, such as "Invoke Ant", "Invoke Maven Targets", etc. You cannot use this automatic installation and then "Execute shell" with ant command there, as that will look for ant in path as any other command line executed directly on the system.
  • Indrajeet
    Indrajeet over 9 years
    With due credit to Slav, I just want to qualify this statement of yours, "However, it will work only if the path to the executable is already present in the PATH env variable of the user with which the slave process is running.". If you invoke the tool (e.g. mvn) in "Execute shell", only then do you need the executable in the PATH env variable. If you are using Jenkins specific implementations, you DO NOT need to have the executable in the PATH env variable.
  • Technext
    Technext over 9 years
    @Indrajeet: Thanks for pointing that out! @Slav is right. Well, so that's one good use of Tool Locations. :)
  • cueedee
    cueedee about 4 years
    I don't see how this answers the OP's question about what the configuration entered under the "Tool Locations" section is actually supposed to achieve....
  • Slav
    Slav about 4 years
    @cueedee read the 4th paragraph in my answer. It is an override per node, instead of using master's global Tool Configuration. As for why OP had original issues, his question is too incomplete to figure out what went wrong. For starters, he mentioned "freestyle" and "mvn" in the same sentence... most likely he did "execute shell" and typed "mvn" there. That is not using Tools, and therefore the whole question becomes irrelevant. My answer explained how to setup and use Tools correctly
  • cueedee
    cueedee about 4 years
    @Slav, thanks for clarifying that. I guess the OP's confusion regarding the "Configure System ❱ Tool Locations" configuration section was, as it was mine, mainly one about documentation; its tooltip says "You can specify the location of certain tools on this node, overriding the global configuration. (You may prefer to use automatic tool installers instead, removing the need to configure each node separately.)" which without more background knowledge doesn't really help to understand what it is for.