Default Suite location / relative path behaviour

[Paul]

Relating to the following (older) post:

how to set relative path for helper suites

Currently i am rediting the helper suit path every time when i move whole main suite folder to other location i.e. initially c:/cp/main.suite later c:/newfolder/main.suite after moving all helper paths needs to be edited How do i set relative path

In the context of having scripts branched in source control to maintain compatibility for older versions, how can we use a relative paths for resources or INitialSuites arguments from the suite, rather than the centrally configured default location? As it stands, all “relative” paths are no more useful that absolute paths as they will need to be updated when the system is branched.

thanks

[ravi4you]

Hello Paul,

Firstly you can update your site info file with a relative path like /main.suite

Whenever you change your location to a different folder can update in default suite location in eggplant functional.

Navigation:Eggplant->Preferences-Default Suite Directory

Add your path like
c:/cp
c:/newfolder

Thanks

[Paul]

This is an impractical solution and not suitable when working across multiple branches. A relative path should be relative to the [current] location and not a centrally defined value.

If you consider “relative paths” in any other application, it is never relative to a statically defined value.

[webbje]

This is probably obvious and something that you’ve rejected already Paul, but what we do, is to define the first part of the path as a variable that is interpolated at runtime by Eggplant to resolve the name of the folder to use to locate a script.

For example, a script could contain a call to a library function (a file containing common code versioned in a separate source code repository) by doing this:

run(CoreFunctions&"\os\h_RDPConnections").clearSecurityMessage

The CoreFunctions variable points to the folder for version 1.1 of the handlers called for RDPConnections, here we’re clearing a security message pop-up.

There are drawbacks with this approach:

• the function locator feature in the Eggplant Functional editor can’t resolve the path to clearSecurityMessage
• if clearSecurityMessage requires images or other resources to work, these dependencies need to be managed sensibly

But the benefit is that teams can use common functions from a separately versioned project which is useful at scale.

Kind regards
Jerry

[Paul]

Hi Jerry

Thanks for taking the time to reply.

I can see where you are coming from, but this also does not cater for a branching strategy. While core functions would be accessible from multiple suites, if we migrate the current version of the suites to a branch (to ensure complete compatibility with a given software version) the variable holding the interpolated value will still be wrong, requiring a per-branch update.
While this is a relatively small impact, the larger issue of a lack of function discovery would outweigh any benefit.

I still assert that eggplants implementation of relative paths goes against what could be considered an industry standard…

[DaveHester]

Hi Paul,
I may have found a solution for you. Within my suite Demo_Scripts, I added my HelperSuite suite using this path
../ScriptRepositories/HelperSuite.suite
Here is the file structure:

When I copied the ScriptRepositories folder from my Windows document folder to c:\temp, I could still access my HelperSuite suite from the Demo_Scripts suite on c:\temp.

I am not certain whether these will create issues for you, but here are the caveats:

• I have only tested this on a Windows instance of ePF v.21.3.1. I do not know whether it will work for other operating systems.
• I have only tested this for instances in which the main suite and the helper suite are both housed within the same folder.

Hope this helps.
Dave