Links

CI/CD Pipeline

Running your tests in CloudBeat from CI/CD pipeline
You can trigger and run your tests in CloudBeat from CI pipeline. CloudBeat takes the hassle of parallelizing and scaling your tests in the CI pipeline, grouping test results and providing standard integration with your CI tool based on JUnit XML format. Beyond the standard JUnit XML based reporting, you can benefit from AI-driven root-cause analysis and quality gating inside CloudBeat UI.

Installing CloudBeat CLI

You can run tests in CloudBeat from any CI tool of your choice. All you need is to install Node.js based CloudBeat-CLI utility and call it from your pipeline's shell step.
To install CloudBeat CLI in your CI environment (assuming Node.js is already installed), use the following shell command:
npm install -g @cloudbeat/cli
This is a pre-build step and is mandatory.
NOTE: If you're running a build on a clean machine each time(Docker, for instance) make sure you have NodeJS installed, and running the installation command (see above) on each build.

Run specified Test Case, Suite or Monitor in CloudBeat

Following command will execute the specified Case, Suite or Monitor, will wait for the tests to finish, and will produce XML report in JUnit format: cloudbeat-cli start <testType> <testId> --apiKey <apiKey> --apiBaseUrl <apiUrl> [folder]
If test execution succeeds exit code will be 0. Otherwise exit code will be 1.
Following command will execute the specified Suite, wait for the tests to finish, and will produce XML file report in JUnit XML format: cloudbeat-cli start <testType> <testId> --apiKey <apiKey> <folder>
<testType> value should be either "case", "suite" or "monitor" and <testId> represents and ID of the correponding executable entity that can be found next to the entity title in CloudBeat's web user interface.
"start" command arguments:
  • testType (required) - Either case, suite or monitor.
  • testId (required) - ID of the test (either case, suite or monitor) to be retrieved from CloudBeat.
  • --apiKey (required) - Your user's API key. Can be retrieved from the user profile settings in CloudBeat.
  • --apiUrl - Optional CloudBeat API address. For SaaS users, it should be https://api.cloudbeat.io. For on-premise users, consult your CloudBeat's system administrator.
  • folder - Optional path to a directory where test results file will be saved. If not specified, results will be saved in the current working directory.
  • -t or --tags <tags> - Optional comma separated tag list to be associated with the test result.
  • -e or --env <environmentName> - Optional name of the environment to be associated with the test. By default, CloudBeat CLI will use the environment set in specified test runtime settings.
  • --envId <environmentId> - Optional ID of the environment to be associated with the test.
  • --build <buildName> - Optional name of the build to be associated with the test result.
  • --release <releaseName> - Optional name of the release or version to be associated with the test result.
  • --pipeline <pipelineName> - Optional pipeline name to be associated with the test result.
  • --sprint <sprintName> - Optional pipeline name to be associated with the test result.
  • --suffix <time | id> - Optional report file name suffix type - must be either "time" or "id"'.
Usage examples:
Running a test case:
cloudbeat-cli start case 70224 --apiKey AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEE
Running a test suite:
cloudbeat-cli start suite 10904 --apiKey AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEE
Passing test attributes (tags):
cloudbeat-cli start case 70224 --apiKey AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEE --tags myTag1Name=MyTag1Val,myTag2Name=myTag2Val

Get specified Test Run status

Following command will retrieve active run's execution status:
cloudbeat-cli run-status <runId> --apiKey <apiKey>

Get Test Result for specified test run

Method can be used for getting status of an finished test:
cloudbeat-cli run-result <rundId> --apiKey=<apiKey>
Additional parameters
Exit code can be controlled with --failOnErrors (true or false). Default is true. For example --failOnErrors=true