Relative paths in remote agent capabilities are incorrectly referenced to agent's directory after upgrade
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Symptoms
An agent has a capability where it finds and runs "Ruby.exe" at a relative path (Ex. : ".\3rdParty\ruby\bin\ruby.exe") from within the existing Perforce workspace directory which is different for each plan - (Ex.: D:\views\<NAME-OF-PERFORCE-WORKSPACE>). After upgrading from Bamboo 4.4.4 to Bamboo 5.3, this relative path gets incorrectly mapped to remote agent's directory (Ex.: "C:\_remote_agent_directory\.\3rdParty\ruby\bin\ruby.exe" instead of staying at: "D:\views\<NAME-OF-PERFORCE-WORKSPACE>\.\3rdParty\ruby\bin\ruby.exe"), which causes all the builds set up with this capability to fail.
Cause
Library used by Bamboo 4.4.4 to spawn external processes adds the following decoration for each invocation:
1
cmd /C /A call actual-commandThe same library is used by Bamboo 5.3 but it only adds that decoration for ".bat" and ".cmd" scripts. So a native Windows call gets executed which fails if the command name is not just a command name but "directory/command-name".
Workaround
Add a "ruby.bat" script to the same directory where "ruby.exe" exists with the following content:
1
2
3
4
5
6
@ECHO OFF
IF NOT "%~f0" == "~f0" GOTO :WinNT
ECHO.This version of Ruby has not been built with support for Windows 95/98/Me.
GOTO :EOF
:WinNT
@"%~dp0ruby.exe" %*Then alter the _WorkspaceRuby_ to be:
1
.\3rdParty\Ruby\win32\bin\ruby.batWas this helpful?