sha's avatar
sha
Contributor
9 years ago
Status:
Implemented

Command line arguments in Jenkins plugin

We have just replaced our old home-grown Jenkins integration with the new 'official' SmartBear Jenkins-TestComplete integration. I find it very easy to work with and it has made our Jenkins integration more 'flashy' and easy to work with for people who are not working with the test system on a daily basis.

 

One feature of our old setup was not possible to reproduce in the new. We sometimes need to run the test on branches of the code (other than the master branch). In our SUT this can be specified in the URL and in the old integration we called TC/TE with a command line argument to specify the branch (if different from master). Unfortunately the new Jenkins integration does not allow for arguments. Adding a field in the UI where you can specify a command line parameter to TestComplete/TestExecute would be nice. This field of course has to allow for variables, so you can pass the information round.

 

This problem can of course be solved in other ways (e.g. dumping the information in a file or environment variable on the slave in Jenkins and read it in TC/TE), but we find our current implementation the most satisfactory. If someone has suggestions on how to implement an alternative, we will be glad to hear them.

 

Yours,

Søren Harder, QA engineer, Zmags

Jenkins

10 Comments

Sort By
  • kixosvk's avatar
    kixosvk
    New Contributor
    9 years ago

    I am missing functionality to pass parameters from Jenkins to Testcomplete in command line.

  • sha's avatar
    sha
    Contributor
    9 years ago

    '

    Perhaps I should explain how we have worked around this issue in our current set-up.

    In Jenkins we have a 'main' job that calls a row of other Jenkins jobs each of which are a wrapper for 1 TestExecute job. (This way we ensure that the jobs are distributed on the available servers). The main job is being run 1) as a SCM job, 2) timed and 3) through the Jenkins UI. And the subjobs may be run in the same ways.

     

    Each of the subjobs use 'Inject environment variables to the build process' to set a EnvVar. (The value is set in the main job as a string parameter and passed down and is the same for all subjobs). Each of the TE tests include a call to a function that sets a variable in the program. This logic is so that it can either 1) be set 'manually' when starting TC/TE (as an extra parameter in the command line that starts TC/TE, specifically we have a bat-file that passes its argument on to its invokation of TC/TE) and 2) be read of an EnvVar set as described above, if the TE is started automatically.

     

    The purpose of this parametrization is to run in different environments, which is being controlled in the URL of the SaaS.

     

    This may sound complex, but it was relatively easy to set up (though I may not have claimed this just after implementing the solution), and has worked now without any problems whatsoever for over 1/2 year.

     

    Søren Harder, QA/Test engineer, Zmags