• Type: Bug
• Resolution: Unresolved
• Priority: Major
• Component/s: customtools-plugin
• Labels:

  • plugin
• Environment:

  Host: OpenJDK 1.8.0_111-8u111-b14-2ubuntu0.16.04.2-b14 running Jenkins 2.32.1 w/customtools-plugin 0.4.4
  Build Agent: Windows 10 (x86) Connected via JNLP agent.

1. 

   screenshot-2.png

   70 kB

   2017-01-11 16:19

2. 

   screenshot-1.png

   50 kB

   2017-01-11 16:17

[JENKINS-40782] Rooted path variables for tool home isn't treated as an absolute path

Elliot Berman created issue - 2017-01-03 19:12

Elliot Berman made changes - 2017-01-03 19:18

Description

Original: When using an environment variable to define the prefix for a custom tool home, such as ${LOCALAPPDATA}, the default home location is still appended to the tool home when it shouldn't be. For example, I have a custom tool called 'mytool' with a trivial batch script installer: {{@echo off echo Installed mytool}} and a custom tool home location of {{${PROGRAMDATA}}} I created a simple pipeline which is: {{node('win') {    bat "echo ${tool 'mytool'}" }}} The expected relevant output should be C:\ProgramData, but is C:\Jenkins\tools\com.cloudbees.jenkins.plugins.customtools.CustomTool\mytool\C:\ProgramData If I manually resolve C:\ProgramData as the tool home (that is, I made the tool home location literally "C:\ProgramData"), then the tool home is configured correctly and outputs only "C:\ProgramData". For some installers, this is acceptable, however I need to use the LocalAppData directory, which contains the username of the build agent. I haven't been able to find a workaround that tricks the tool home into thinking it's rooted path. I was able to reproduce this issue using the same methodology on both the host build agent, Ubuntu, and on a remote build agent, Windows. Let me know if there's anything I can do to help out.

New: When using an environment variable to define the prefix for a custom tool home, such as ${LOCALAPPDATA}, the default home location is still appended to the tool home when it shouldn't be. For example, I have a custom tool called 'mytool' with a trivial batch script installer: @echo off echo Installed mytool and a custom tool home location of ${PROGRAMDATA} I created a simple pipeline which is: node('win') {    bat "echo ${tool 'mytool'}" } The expected relevant output should be C:\ProgramData, but is C:\Jenkins\tools\com.cloudbees.jenkins.plugins.customtools.CustomTool\mytool\C:\ProgramData If I manually resolve C:\ProgramData as the tool home (that is, I made the tool home location literally "C:\ProgramData"), then the tool home is configured correctly and outputs only "C:\ProgramData". For some installers, this is acceptable, however I need to use the LocalAppData directory, which contains the username of the build agent. I haven't been able to find a workaround that tricks the tool home into thinking it's rooted path. I was able to reproduce this issue using the same methodology on both the host build agent, Ubuntu, and on a remote build agent, Windows. Let me know if there's anything I can do to help out.

Elliot Berman made changes - 2017-01-03 19:19

Description

Original: When using an environment variable to define the prefix for a custom tool home, such as ${LOCALAPPDATA}, the default home location is still appended to the tool home when it shouldn't be. For example, I have a custom tool called 'mytool' with a trivial batch script installer: @echo off echo Installed mytool and a custom tool home location of ${PROGRAMDATA} I created a simple pipeline which is: node('win') {    bat "echo ${tool 'mytool'}" } The expected relevant output should be C:\ProgramData, but is C:\Jenkins\tools\com.cloudbees.jenkins.plugins.customtools.CustomTool\mytool\C:\ProgramData If I manually resolve C:\ProgramData as the tool home (that is, I made the tool home location literally "C:\ProgramData"), then the tool home is configured correctly and outputs only "C:\ProgramData". For some installers, this is acceptable, however I need to use the LocalAppData directory, which contains the username of the build agent. I haven't been able to find a workaround that tricks the tool home into thinking it's rooted path. I was able to reproduce this issue using the same methodology on both the host build agent, Ubuntu, and on a remote build agent, Windows. Let me know if there's anything I can do to help out.

New: When using an environment variable to define the prefix for a custom tool home, such as ${LOCALAPPDATA}, the default home location is still appended to the tool home when it shouldn't be. For example, I have a custom tool called 'mytool' with a trivial batch script installer: @echo off echo Installed mytool and a custom tool home location of ${PROGRAMDATA} I created a simple pipeline which is: node('win') {    bat " echo ${tool 'mytool'} " } The expected relevant output should be C:\ProgramData, but is C:\Jenkins\tools\com.cloudbees.jenkins.plugins.customtools.CustomTool\mytool\C:\ProgramData If I manually resolve C:\ProgramData as the tool home (that is, I made the tool home location literally "C:\ProgramData"), then the tool home is configured correctly and outputs only "C:\ProgramData". For some installers, this is acceptable, however I need to use the LocalAppData directory, which contains the username of the build agent. I haven't been able to find a workaround that tricks the tool home into thinking it's rooted path. I was able to reproduce this issue using the same methodology on both the host build agent, Ubuntu, and on a remote build agent, Windows. Let me know if there's anything I can do to help out.

Elliot Berman made changes - 2017-01-11 16:14

Attachment

New: python3-custom-installer.png [ 35434 ]

Elliot Berman made changes - 2017-01-11 16:17

Attachment

New: screenshot-1.png [ 35435 ]

Elliot Berman made changes - 2017-01-11 16:19

Attachment

New: screenshot-2.png [ 35436 ]

Elliot Berman made changes - 2017-01-11 16:22

Attachment

Original: python3-custom-installer.png [ 35434 ]

Oleg Nenashev made changes - 2019-01-02 09:30

Assignee

Original: Oleg Nenashev [ oleg_nenashev ]