Add an event for Report post-processing
The need In ReadyAPI there are nice options of reporting, however there is missing any function to do report post-processing. The post-processing needs are: to send a report via email put the report into a storage create a Jira item etc. Currently the report files are just placed in the output directory. On TestCase and TestSuite level there are Report script holders, but the purpose of the script is to extend the reporting options (it is executed before the reports are finished, not after), i.e. for report pre-processing. On the project level there is no such option. Solution proposal A good place to execute specific actions are the events. But there is no "ReportListener.afterReport" event. Please add a new event ReportListener.afterReport which will be triggered after any report is finished by testrunner. Such event will be used by Groovy scripts to do the report post-processing.Allow user to set logging level for maven-plugin via project configuration file
currently, when running the readyApi maven plugin, the logging level is set to info. We need a mechanism to set it to error or warning because the excessive logging is crashing our build slave. This could be done in the plugin configuration section of the pom.xml. Or the maven plugin could respect the user's log4j configuration files.
Distroless docker images for Test Runner and LoadUI Agent
Dear Smartbear, we are planning to use the pre-configured Docker images (Test Runner and LoadUI Agent) to run tests in our GitLab CICD pipelines. But after consulting with our IT Security Department, only distroless images are allowed to use within our company. The bare minimum of a distroless image - as required by our IT Security Guideline - is that it contains no package manager. It can be achieved, for example, by a multi-stage docker build, in which the package manager is removed at the last stage. Thus, I would like to ask you to provide officially distroless Docker images for the Test Runner and LoadUI Agent. In addition, distroless Docker images are becoming best practices and the default choice for deployment containers. So I'm pretty sure, that a lot of your users would benefit from it 🙂 Thank you very much in advance! Best regards, your ReadyAPI userReadyAPI- Authentication Manager - Collaps all API's and testsuite on opening
Hello, As well as I'm not working everyday in my Auth Manager, I'm noticing a bit of an irritable thing. When you open the Auth Manager all API's and all TestSuites/TestCases/TestSteps are open, not collapsed. When you have a lot of API's to manage in a project, it is a little cumbersome to each time close all the API's and TestSuites/TestCases/ up the one you're searching for. Or even to scroll down to more-or-less the place where you're expecting to find them. Could it be possible to make them collapsed per default please? thanks in advance, AAB
Check out Floating Licenses on Headless Machines
Hello everyone, I am new here and need your help. How to pass your user data when using License Manager to get a license from ReadyAPI floating license server. You have to pass your username somehow so that the license server can do the LDAP query. For example: java -jar ready-api-license-manager-1.3.3.jar -c UserName -s <serverIP>:443
Default environment usable as an actual environment
Hello, in one of the recent versions we pretty much lost the ability to use the "default environment" as a real environment. It was even renamed to "no environment". I've used it as the "development" one and I was creating extra one for the higher - "test" environment. Now the default environment can't be really used to set up authorization to given endpoints for our APIs. I can't even copy it as a template for a new environment, meaning i have to create a new one from the scratch. Having to do that in multiple projects with plenty of API's and custom properties means huge extra time commitment to manage projects in our company's department. Can you please unlock the ability to clone this default environment and set authorization /proxy for the APIs? Thank you, JohnUse xinclude to externalize environments/endpoints
We have 5 environments we need to target (CI/CD, DEV, TEST, PROD, SANDBOX). We have 30 apis with new apis on the horizon. On average each project will require two environments (for the Auth api and the api under test). Rather than have 30 copies of the Auth api details (one for each api) we would prefer to externalize "shared" details via the use of xinclude. That way, when/if the Auth api environment/endpoint details change we only have to apply a single update which will subsequently "trickle down" to all the projects that leverage the shared content.
Add password parameter for the loadtestrunner
Hello, I'm using the latest version from RedayAPI (3.0.0) and my project is password protected - the properties are encrypted. When I want to run functional tests in pipeline, I can give the password over the command-line parameter -p but this parameter doesn't exists for the loadtestrunner. This fact is not an error but a missing function. Without this feature, encoding the properties in a project is a major drawback when you want to automate the load test because I must deactivate the passwort protection to run the loadtestrunner. This is a strong security restriction, especially if you want to protect the passwords/token/secrets used in cloud repositories. A lot of services are provided in the cload nowadays and the trend is increasing, besides the reason I ask the reader to vote for the function to introduce the password parameter for the loadtestrunner as well. Thanks in advance for the votes. Greetings, GiovanniTestEngine + Jenkins Plugin: Execute list of Project/Suite/Case SoapUI tests
In their current implementation 1.) the TestEngine needs to be provided a zip with all required files by the calling client 2.) the TestEngine Jenkins plugin will execute one Project/Suite/Case per Jenkins job Problem: This setup does not scale to execute many Project/Suite/Case SoapUI tests in a row Suggestion: ad 1.) a.) Provide TestEngine the ability to access/checkout GIT repos containing SoapUI Projects b.) Add an API to TestEngine that will take the Project/Suite/Case/... parameters and pick all required files from above local checkout area --> Like this no files need to be created/transfered to the TestEngine server What still needs to be done is the specification of the list of Project/Suite/Case to be executed. This could be provided by one or more config files maintained in the GIT repo(s) ad 2.) In case the TestEngine runs on the Jenkins slave(s), the Jenkins job could - checkout the GIT repo(s) - locate the config file(s) containing the list of /Project/Suite/Case SoapUI Tests in the checkout area (e.g. via parameter) - loop the config file(s) calling the TestEngine API with Project/Suite/Case/... parameters --> like this - The TestEngine is running as a server (contrary to testruner.sh) - The invocation of many Project/Suite/Case's will run with minimal overhead (presumably msecs instead of secs) - all required files are taken from a repo -> any updates propagate to TestEngine automatically Remark: This type of automated execution of SoapUI Test from different Project/Suite/Case needs to complemented with a suitable test report (e.g. csv file with Project/Suite/Case/Step, timeStamp, Status, ExecTime, ErrorMsg, ...
