• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • customtools-plugin
    • None
    • Jenkins 1.599; Windows 7 x64
      Java SE Runtime Environment: 1.7.0_25-b17

      I have tested the Custom Tools plugin to (automatically) installing a zip- or tar.gz archive; which works fine.

      Assuming, that is it possible to overrride the tool-location, I have configured and (alternative) Home (in Configure System -> Tool Locations).
      The previously configured tool (eg. "gcc-4.9.2-i386") is listed in the drop-down box as "(Custom Tool) gcc-4.9.2-i386"; but the configured folder isn't used (in the job-run).
      The archive is still installed/unpacked in the default-directory
      (Ie. "C:\..\Jenkins\tools\com.cloudbees.jenkins.plugins.customtools.CustomTool\gcc-4.9.2-i386").

      Best regards from Salzburg,
      Markus

          [JENKINS-27157] Overriding Tool location(s) has no effect

          Oleg Nenashev added a comment -

          Markus, do you run your job on the master node?
          The described use-case definitely works well on slaves.

          Oleg Nenashev added a comment - Markus, do you run your job on the master node? The described use-case definitely works well on slaves.

          Markus Eisenmann added a comment - - edited

          Hi!

          Yes, I've run the (test-) job on the master!

          To understand my use-case:
          Currently, we are using a variable like "JOBS_WORKS_ROOT", which is defined for the master and each slave (specific). This variable defines the root-directory which contains (at least) all wokspaces. The (main-) tools are located under ${JOBS_WORKS_ROOT}\shared\tools\<tool-name> and each job - regardless whether it runs on the master or an a slave - can use use these "relative" setup of tools.
          My idea was, to configure "${JOBS_WORKS_ROOT}\shared\tools\<tool-name>" as home location to get the same behaviour (but with automatic download and installation).

          Up to now, I've not tested, whether the location-override has an effect on slaves
          As work-around I've already determined, that a (hard) directory-link (Jenkins\tools\com.cloudbees.jenkins.plugins.customtools.CustomTool -> ${JOBS_WORKS_ROOT}\shared\tools) does redirect the installation to get a similar behaviour.

          Best regards from Salzburg,
          Markus

          Markus Eisenmann added a comment - - edited Hi! Yes, I've run the (test-) job on the master! To understand my use-case: Currently, we are using a variable like "JOBS_WORKS_ROOT", which is defined for the master and each slave (specific). This variable defines the root-directory which contains (at least) all wokspaces. The (main-) tools are located under ${JOBS_WORKS_ROOT}\shared\tools\<tool-name> and each job - regardless whether it runs on the master or an a slave - can use use these "relative" setup of tools. My idea was, to configure "${JOBS_WORKS_ROOT}\shared\tools\<tool-name>" as home location to get the same behaviour (but with automatic download and installation). Up to now, I've not tested, whether the location-override has an effect on slaves As work-around I've already determined, that a (hard) directory-link (Jenkins\tools\com.cloudbees.jenkins.plugins.customtools.CustomTool -> ${JOBS_WORKS_ROOT}\shared\tools) does redirect the installation to get a similar behaviour. Best regards from Salzburg, Markus

          Hi!

          I have run some tests to determine additional information on this issue:

          1. Global configuration:
          Custom tool installation "gcc-4.9.2-i386" as ZIP-Download; Sub-directory of extracted archives = bin (Ie. sub-folder of executable).
          Overriden (global) tool-location of "(Custom tool" gcc-4.9.2-i386"): Home = C:\tools\master\gcc-4.9.2-i386

          2. Addition slave 'SLAVE1', with
          tool-location of "(Custom tool) gcc-4.9.2-i386": Home = C:\slave\tools\gcc-4.9.2-i386

          A) If a job (with installing this tool) runs on master, following occurs

          • Download and unpacking to C:\webserver\Jenkins\tools\com.cloudbees.jenkins.plugins.customtools.CustomTool\gcc-4.9.2-i386
            (in not already done)
          • Setting GCC-4.9.2-I386_HOME=C:\webserver\Jenkins\tools\com.cloudbees.jenkins.plugins.customtools.CustomTool\gcc-4.9.2-i386\bin
          • This location (GCC-4.9.2-I386_HOME) is added to the environment variable PATH

          Note: The (global) configured tool-location isn't used.

          B) If the same job run on a slave (Ie. SLAVE1, configured as written above), following occurs:

          • Setting GCC-4.9.2-I386_HOME=C:\slave\tools\gcc-4.9.2-i386
          • This location (GCC-4.9.2-I386_HOME) is added to the environment variable PATH

          As result of the configured tool-location (for this tool on a slave):

          • No download und unpacking takes place.
          • The sub-directory (bin) isn't added to the configured tool-location.

          Based on these tests, my personal conclusio is: Don't configure a tool location;
          to "enforce" a similar behavior (+ automatic installation) on master and slave(s).

          Maybe the feature-request as describe in https://issues.jenkins-ci.org/browse/JENKINS-27158 can be implemented in a future release:
          Optionally disabling add of HOME-directory to PATH-variable (but that's my personal opinion/wish).

          BR,
          Markus

          Markus Eisenmann added a comment - Hi! I have run some tests to determine additional information on this issue: 1. Global configuration: Custom tool installation "gcc-4.9.2-i386" as ZIP-Download; Sub-directory of extracted archives = bin (Ie. sub-folder of executable). Overriden (global) tool-location of "(Custom tool" gcc-4.9.2-i386"): Home = C:\tools\master\gcc-4.9.2-i386 2. Addition slave 'SLAVE1', with tool-location of "(Custom tool) gcc-4.9.2-i386": Home = C:\slave\tools\gcc-4.9.2-i386 A) If a job (with installing this tool) runs on master, following occurs Download and unpacking to C:\webserver\Jenkins\tools\com.cloudbees.jenkins.plugins.customtools.CustomTool\gcc-4.9.2-i386 (in not already done) Setting GCC-4.9.2-I386_HOME=C:\webserver\Jenkins\tools\com.cloudbees.jenkins.plugins.customtools.CustomTool\gcc-4.9.2-i386\bin This location (GCC-4.9.2-I386_HOME) is added to the environment variable PATH Note: The (global) configured tool-location isn't used. B) If the same job run on a slave (Ie. SLAVE1, configured as written above), following occurs: Setting GCC-4.9.2-I386_HOME=C:\slave\tools\gcc-4.9.2-i386 This location (GCC-4.9.2-I386_HOME) is added to the environment variable PATH As result of the configured tool-location (for this tool on a slave): No download und unpacking takes place. The sub-directory (bin) isn't added to the configured tool-location. Based on these tests, my personal conclusio is: Don't configure a tool location; to "enforce" a similar behavior (+ automatic installation) on master and slave(s). Maybe the feature-request as describe in https://issues.jenkins-ci.org/browse/JENKINS-27158 can be implemented in a future release: Optionally disabling add of HOME-directory to PATH-variable (but that's my personal opinion/wish). BR, Markus

          Oleg Nenashev added a comment -

          I will have a really small bandwith in the community in the next months, see https://groups.google.com/d/msg/jenkinsci-dev/uc6NsMoCFQI/AIO4WG1UCwAJ for the context. I decided to mark this plugin for adoption and unassigned tickets so that anybody is welcome to take over the plugin and to become a maintainer. Some tickets already have pending pull requests which can be finalized.

          Oleg Nenashev added a comment - I will have a really small bandwith in the community in the next months, see https://groups.google.com/d/msg/jenkinsci-dev/uc6NsMoCFQI/AIO4WG1UCwAJ for the context. I decided to mark this plugin for adoption and unassigned tickets so that anybody is welcome to take over the plugin and to become a maintainer. Some tickets already have pending pull requests which can be finalized.

            Unassigned Unassigned
            ibiatiroler Markus Eisenmann
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: