Forum Discussion

JohanH's avatar
JohanH
Occasional Contributor
9 years ago

Jenkins Environment Variables not available in Tests

  Hi,

 

I'm using Jenkins to trigger scheduled tests and have recently started to use parameters in Jenkins. The parameters are set as environment variables by Jenkins and can easily be accessed by scripts executed on the Jenkins slave but not from the tests run by TestExecute in the same job.

 

I need to parameters to be able to control which test system I should access  from my tests. Sure I could copy the tests, one for each target, and hard code the target in each test, but that would quickly lead to a maintenance nightmare, thus I thought of using Jenkins parameters (and Multi-configuration variables) to do the job for me.

 

Anyone tried this and found a solution to get this working? 

 

My setup is as follows: Jenkins, TestComplete Jenkins plugin, Java Web Start as service (on Jenkins slaves), TestExecute, Test written in python.

 

Issue filed in support request: Case #00181940: "Environment variables form Jenkins not available in TestExecute"

 

  BR, Johan

 

  • After much hard work I figured out what the problem is.

     

    We have installed Jenkins on the Slaves using Java Web Start as a service as described in the help section. The service is running as the System user. The TestComplete jenkins plugin is running on a different account (with admin rights). 

     

    This means that any environment variables set up by Jenkins is set in the System user environment and is not accessible to the other users and processes running under those accounts, in this case the TestComplete process...

     

    I did try to run as the same user (i.e changing the user of the Jenkins slave service) and it worked for the environment variables but then I lost the possibility to interact with the desktop... very bad for GUI based application testing.

     

    So in the end we came up with this solution:

     

    1. In Jenkins add a 'Execute Windows batch command' build before the 'TestComplete Test' and write:

      set > %SystemRoot%\Temp\environment-variables-from-jenkins.txt

      Since we cannot access the environment variables we are forced to use a location we think exists in and is accessible by both accounts.

    2. In our Test we have written the following code that reads the file and sets the variables if the do not exist.
      # -------------------------------------------------
      # Read eventual environment variables file to
      # enable Jenkins (or other) to transfer settings
      # by means of environment variables
      # -------------------------------------------------
      env_file = os.path.join(os.getenv('SystemRoot'),
      'Temp', 'environment-variables-from-jenkins.txt') if os.path.exists(env_file): with open(env_file) as f: lines = f.readlines() if lines: for name, value in [line.split('=', 1) for line in lines if line]: if not os.getenv(name): os.putenv(name, value.strip()) os.unlink(env_file)
      Do not forget to remove the file after read! Otherwise environment variables from one test may taint another.

    Hope this may help others that run into the same issue. If you by chance have solved this in another way, please post your findings here.

  • JohanH's avatar
    JohanH
    Occasional Contributor

    After much hard work I figured out what the problem is.

     

    We have installed Jenkins on the Slaves using Java Web Start as a service as described in the help section. The service is running as the System user. The TestComplete jenkins plugin is running on a different account (with admin rights). 

     

    This means that any environment variables set up by Jenkins is set in the System user environment and is not accessible to the other users and processes running under those accounts, in this case the TestComplete process...

     

    I did try to run as the same user (i.e changing the user of the Jenkins slave service) and it worked for the environment variables but then I lost the possibility to interact with the desktop... very bad for GUI based application testing.

     

    So in the end we came up with this solution:

     

    1. In Jenkins add a 'Execute Windows batch command' build before the 'TestComplete Test' and write:

      set > %SystemRoot%\Temp\environment-variables-from-jenkins.txt

      Since we cannot access the environment variables we are forced to use a location we think exists in and is accessible by both accounts.

    2. In our Test we have written the following code that reads the file and sets the variables if the do not exist.
      # -------------------------------------------------
      # Read eventual environment variables file to
      # enable Jenkins (or other) to transfer settings
      # by means of environment variables
      # -------------------------------------------------
      env_file = os.path.join(os.getenv('SystemRoot'),
      'Temp', 'environment-variables-from-jenkins.txt') if os.path.exists(env_file): with open(env_file) as f: lines = f.readlines() if lines: for name, value in [line.split('=', 1) for line in lines if line]: if not os.getenv(name): os.putenv(name, value.strip()) os.unlink(env_file)
      Do not forget to remove the file after read! Otherwise environment variables from one test may taint another.

    Hope this may help others that run into the same issue. If you by chance have solved this in another way, please post your findings here.

    • mgroen2's avatar
      mgroen2
      Super Contributor

      JohanH You might want to tell support about your resolution, so they can report it to the SmartBear Technical Writer, to update the online documenation.

      • Ashcutus's avatar
        Ashcutus
        Occasional Contributor

        Hi guys,

         

        Have any support docs been updated to reflect this work around using the other supported languages?

         

        I need to do something similar, but we are using Jscript in our tests.

         

        Cheers,

        Ben

  • We have written similar scripts in our environment that write out the environment variables to a file which then can be read from the test.  It would be nice if there were a more fluid way of doing it, but it does work for us.