Dear SmartBear Support,
My orgnanization and I have been leveraging SoapUI Professional for many years as the primary functional testing tool for our various SOAP-based and RESTful web services. As part of our SDLC, we (software quality engineers) develop such functional test scripts/suites using our development systems, check them into source control (Stash/Bitbucket), and invoke them via Maven on our CI (Jenkins) server in an integrated application testing environment. This approach has served us well for quite some time, until recently, when we attempted to upgrade our testing infrastructure from SoapUI Pro to Ready API Pro. The issue pertains to licensing, where I understand now that headless Ready API Maven plug-in executors will require a valid license to be present, where this was not always required/enforced with SoapUI.
Since I have a valid, activated Ready API license on my development workstation, I attempted to copy this, along with the associated licensing files, to the ".soapui" directory on the Jenkins server for the account under which Jenkins executes (e.g., /export/home/users/<jenkins_user>/.soapui/). Upon invocation of our Ready API test scripts via Jenkins, the Ready API Maven plug-in indicated that no valid license was found and prompted for user confirmation to install one. Since this is a headless executor, the invocation/build consistently fails at this point. The question that I had was whether we actually had to purchase individual Ready API Professional licenses for each of our Jenkins build executors, which we have 10 of, or if we could leverage the same license that we use to develop the functional test scripts? The challenge is that we develop the scripts on a development workstation, confirm their validity, and ultimately check them into source control for long-term automated execution via Jenkins. Is it the case that we would need a license for the system responsible for developing the scripts and another for the system responsible for executing them?
I was reading several community posts which discussed having to modify the account under which Jenkins runs under, to match that of the user that was used during the initial license activation, but in our case, that is not a possible solution (and seems rather restrictive). In that case, I would have to re-configure the (10) Jenkins instances (all Linux servers) to match the user account of my personal development system (Mac OS X). I am not sure whether the operating system needs to be considered, but seems possible if you are somehow dealing with user accounts. The documentation provided on the SmartBear site referred specifically to Jenkins running as a Windows service, so that recommendation did not necessarily apply to our configuration.
Given the dilemma that we are facing, I was wondering if you have assisted other community members in similar situations, and if so, whether you could provide us with a possible resolution?
And if there are any additional details that I can provide, please let me know.
Thanks in advance for your time and assistance - it is greatly appreciated!
Solved! Go to Solution.
I faced similar kind of situation when out jenkins server was running under differnt account and i installed soapUI under differnt account . As i have already activated the license copying and al other things did not work . So i open the case with support and got my license deactivated . after that i did intsall on linux under the same account which jenkins uses for running the job.
is it the case that we would need a license for the system responsible for developing the scripts and another for the system responsible for executing them?
As i have fixed license so i did have differnt license on devmachine and jenkin machine.
I am not sure if it helps in your case.
Thanks a lot for the feedback and for providing a potential solution for our licensing predicament. I was considering taking that very same route, the only issue that I feared was that I would no longer have an active license for my test script development system (since it would require deactivation and transferral to our Jenkins executor(s) instead).
As you did, I will try and work with the Support team to determine what our available options are. And thanks again for the comments/suggestions Vk - very much appreciated.
Het Tim and Vk,
I see you both have implemented Ready API- Jenkins for CI in your organization.I am looking into how this is done and pretty much stuck.Will you be able to give some tips and tricks plus key bullets on where to start ?