# What is CloudBeat? ![](/files/-MRjzlJjq_ju8vEFi6Iv) **CloudBeat** is a centralized **continuous quality** platform that helps create, execute and analyze unit, API, integration and end-to-end tests in a **DevOps** environment. ![](/files/-MRk-JRmMLCJMWbXZbq7) ![](/files/-MRk-mVKGNhPI4rvenIV) CloudBeat seamlessly integrates with the most **popular testing frameworks** and **CI tools**, allowing to run large test sets with out of the box parallelization, test lab management, and failure root cause analysis. Our mission is to help you to increase your software quality, reduce testing and development time and eventually improve your customer satisfaction. ### **More information** * Check out the [CloudBeat](http://cloudbeat.io/) website for more details * Request a [demo](http://cloudbeat.io/#demo). ### **Coding integrations** * [Oxygen](http://oxygenhq.org/) * [Cucumber](https://cucumber.io/) * [TestNG](https://testng.org/doc/) ### **CI/CD integrations** * [TFS](https://visualstudio.microsoft.com/team-services/tfs-pricing/) * [Jenkins](https://jenkins.io/) * [GitHub](https://github.com/) # Quick Start ### **Getting started with CloudBeat** * [Create a project (here's how).](/references/projects) * Optional **- If you haven't synced your project with your Git repository,** [Upload or create](https://docs.cloudbeat.io/get-started/pages/-Luhc-fk8BlUgP0DH6ER#Edit/Upload-the-test-case) your existing test cases to CloudBeat * [Run your tests on multiple platforms](/fundamentals/executing-tests). ### **Infrastructure selection** If you/your company haven’t decided on an automation testing infrastructure just yet… here’s a great [open-source and completely free to use framework](http://oxygenhq.org/) that integrates perfectly with CloudBeat, with easy “Plug\&Play” entrance to automation testing, JavaScript based. P.S: If you already chose a different infrastructure for your automation testing, we also support other popular frameworks such as: * Java + Cucumber * Java+ TestNG * C# + MSTest ### **First things first** Congratulations on joining the best testing/devops platform ever!\ In order to get started, project creation is needed, create your project in projects screen. For more detailed information on creating your projects - [Projects Screen](https://docs.cloudbeat.io/references/untitled-5). ### **Customize your tests** Create a folder by right clicking the dashboard, type the folder name and create it. After creating the folder, you may create a test case (Web or Mobile) by right clicking the folder and choosing create button , once you created a test, you may select it by clicking it. When selecting a case from the left panel - a table of options will be opened to the right (In the center of the screen). The menu contains the following: * Details: Describe in words the what the test case is about (free text). * Settings: Choose the settings you want your test to run with. * Script: Write/Load the source file. * Devices/Browsers:Choose which server and which Browser/Device you want to run on. * Parameters: Load a parameter file (CSV/XLSX) * Schedule: Choose a schedule you want to run automatically (on demand by default). ### **Run test “Suites”** Create a folder by right clicking the dashboard, type the folder name and create it. Right click the folder you created and choose “Create Suite - Web” or “Create Suite - Mobile”. After creating the suite, you may select it by clicking it in the left panel. When selecting a suite from the left panel - a table of options will be opened to the right (In the center of the screen). The menu contains the following: * Settings: Choose the settings you want your test to run with. * Cases: Select the cases you want to be contained in the specific suite. * Devices/Browsers:Choose which server and which Browser/Device you want to run on. * Parameters: Load a parameter file (CSV/XLSX) * Schedule: Choose a schedule you want to run automatically (on demand by default). * Notifications: Select a group to be sent a notification via email with the suite result once finished. After you have your tests configured under the “Cases” screen, you can now run multiple tests (Suites) and receive detailed reports and run each test with a different setting (More than one iteration, separate parameter file attached on a case level) # Java JUnit This example project shows how to run JUnit tests in Java with Cloudbeat integration. It’s a simple way to get started with running your tests in the cloud and viewing results in real time. ## Installation First we need to include the Cloudbeat dependencies inside our pom.xml: ``` io.cloudbeat cb-kit-selenium4 LATEST io.cloudbeat cb-kit-common LATEST io.cloudbeat cb-kit-junit5 LATEST ``` If you want to use a specific version, include it inside properties: ``` 1.0.11 ``` Then instead of LATEST, use cloudbeat.version ```xml io.cloudbeat cb-kit-selenium4 ${cloudbeat.version} ``` {% hint style="info" %} For on-prem, we can install the Cloudbeat kit using files stored locally {% endhint %}
We need to specify the version of the jar files: ``` 1.0.11-SNAPSHOT ``` Then install the dependencies: ``` mvn clean install ``` ## Implementing Cloudbeat Reporting We need to start by importing the Cloudbeat step extension inside our methods file: ``` import io.cloudbeat.common.annotation.CbStep; ``` Then, add CbStep above your method: ``` @CbStep("Open Base URL") public void open() { driver.get(baseUrl); } ``` Import CloudBeat Junit extension in our tests: ``` import io.cloudbeat.junit.CbJunitExtension; ``` Extend Cloudbeat JUnit extension class: ``` import org.junit.jupiter.api.extension.ExtendWith; @ExtendWith({ CbJunitExtension.class }) public class LoginTest { private WebDriver driver; private LoginPage loginPage; @BeforeEach public void setUp() { driver = DriverManager.getDriver(); loginPage = new LoginPage(driver); } } ``` Wrap your test steps using startStep & endLastStep: ``` @Test @DisplayName("Standard User Login Behaviour") public void standardUserLoginBehaviour() { CbJunitExtension.startStep("Open Main Page"); loginPage.open(); loginPage.assertPageOpen(); CbJunitExtension.endLastStep(); } ``` ## Creating a Java JUnit project in Cloudbeat Under Manage, open projects and click on add project, choose a name and select Java JUnit.
### Connect your test project to CloudBeat CloudBeat is a platform for both test reporting and execution. To use CloudBeat, you must upload your test project files to execute tests and access report analytics. You can upload your project as a Zip file, or CloudBeat can automatically synchronize with your test project Git repository. ### Git synchronization In order to sync your test project from git, select Git Integration and paste the url to your repository. You can use your username and password, or with an access token. ### Uploading manually If you want to upload a local test project, you need to zip your project folder, then select upload.
## Running your tests Under Testing, go to cases and you will see all your tests. Under each test you will find multiple options such as choosing who will receive notifications for this test, schedule when the test will run, choosing environments and parameters and the browser it will run on.
Click on Run Now to execute the test, then the results will appear under the Results tab. To expend the results and see all the steps, data, logs and errors, click on case summary:
### Running multiple tests Under Testing, go to Suites, right-click on Dashboard to create a new suite, or start by creating a new folder then right-click on it and choose Create suites - web.
Similarly to single tests, select your browser and other configurations:
Select your desired tests:
Click on Save Changes and then Run Now. The results will wait for you under the results tab.
# .NET MSTest ## Installation We need to include the MSTest kit by using: ``` dotnet add package CloudBeat.Kit.MSTest ``` ### Install a specific version of a package ``` dotnet add package CloudBeat.Kit.MSTest --version 4.7.0 ``` ## Initialization import: ``` using CloudBeat.Kit.MSTest; ``` Inherit the CbTest class and wrap the webdriver: ``` namespace CbExamples.MSTest.Infra { [TestClass] public abstract class WebDriverTest : CbTest { private IWebDriver _driver = null; public EventFiringWebDriver Driver { get; private set; } [TestInitialize] public void SetUpWebDriver() { ChromeOptions options = new ChromeOptions(); _driver = new ChromeDriver(options); Driver = new EventFiringWebDriver(_driver); CbMSTest.WrapWebDriver(Driver); } } } ``` ## Applying CBStep Attribute in your test cases Import: ``` using CloudBeat.Kit.MSTest.Attributes; ``` Use attribute **\[CBStep]** to describe your test case: ``` [CbStep("Open \"Login\" page")] public void Open() { driver.Navigate().GoToUrl(baseUrl ?? DEFAULT_BASE_URL); } ``` You can also use variables in the step description, to do that we'll put **username** in curly braces: ``` [CbStep("Type \"{username}\" in \"Username\" field")] public void EnterUsername(string username) { var usernameFld = UsernameField; if (usernameFld == null) Assert.Fail("Username field not found"); usernameFld.Click(); usernameFld.SendKeys(username); } ``` ## Create Binaries Before uploading our project to CloudBeat, we have to create a binaries zip folder, in your project folder open cmd and run the following command: ``` dotnet build ```
a bin folder should be created, now go to bin -> debug and create a zip from net.6.0
## Creating MSTest project in Cloudbeat Go to projects tab and create a new project and choose **MSTest - Binaries** {% content-ref url="/pages/-Luhc-7l\_JV43u6esfU6" %} [Projects](/references/projects) {% endcontent-ref %}
Decide who will have accessibility to this project
Upload the binaries as a zip
Add assembly names and finish
And that's how you have a new MSTest project
## Running Test Cases Go to Cases under Testing tab, there you will see all your test cases {% content-ref url="/pages/-LuhLvlMu9fDYoHu0rJI" %} [Running Tests Cases](/fundamentals/executing-tests) {% endcontent-ref %}
Select a browser to run your test on, save changes and run
You will see the results based on the **\[CbSteps]** that were added in your project
# Playwright (JS/TS) Integrating Playwright JavaScript/TypeScript based tests ## Installation First we need to install cloudbeat/playwright in your project: ``` npm install @cloudbeat/playwright ``` Then add cloudbeat as the reporter inside playwright.config: ``` reporter: process.env.CB_AGENT ? '@cloudbeat/playwright' : 'html' ``` In order to save screenshots and videos in cloudbeat, make sure to enable them: ```typescript use: { trace: "on-first-retry", video: "on-first-retry", screenshot: "only-on-failure", headless: process.env.CB_AGENT ? true : false }, ``` {% hint style="info" %} When setting `video`, `screenshot`, or `trace` to `on`, Playwright will generate attachments for **every action**, even if it succeeds. This is generally **not recommended**, as it creates many unnecessary files and increases storage and execution time.\ Instead, it's better to use the `on-first-retry` option, which only captures these artifacts if a test fails for the first time (on the first retry). This approach provides a good balance between debugging needs and resource efficiency. {% endhint %} {% hint style="info" %} Since CloudBeat agents run on Linux-based environment, enabling headless mode is mandatory and resulting in faster test execution and more efficient CPU and memory utilization. {% endhint %} ## Creating a Playwright project in Cloudbeat Under Manage, open projects and click on add project, choose a name and select Playwright
### Connect your test project to CloudBeat CloudBeat is a platform for both test reporting and execution. To use CloudBeat, you must upload your test project files to execute tests and access report analytics. You can upload your project as a Zip file, or CloudBeat can automatically synchronize with your test project Git repository. ### Git synchronization In order to sync your test project from git, select Git Integration and paste the url to your repository. You can use your username and password, or with an access token. ### Uploading manually If you want to upload a local test project, you need to zip your project folder, then select upload. {% hint style="warning" %} **Make sure you skip node\_modules, and preferably all the unnecessary files such as results, reports, etc.** {% endhint %}
## Configuring Environments Under manage, open Environments and recreate the values that you have inside your .env file.
## Running your tests Under Testing, go to cases and you will see all your tests, make sure Location is enabled under test mode, click on Run Now to execute the selected test on your selected location.
After your test is completed, click on the results tab to see all of the test steps, videos, logs and data.
### Running multiple tests Under Testing, go to Suites, right-click on Dashboard to create a new suite, or start by creating a new folder then right-click on it and choose Create suites - web.
Go to settings and make sure test mode is set to Location, save changes and choose your location.
Click on the cases tab and select your desired cases.
Similar to a single case, clicking on Run Now will execute all the selected cases.
Under results tab, you will see the status of your tests.
# Python Pytest This example project shows how to run Python Pytest with Cloudbeat integration. It’s a simple way to get started with running your tests in the cloud and viewing results in real time. ## Installation {% hint style="info" %} If you're starting from scratch, we need to create a python environment inside your project first and activate it {% endhint %} ``` python -m venv env env\Scripts\activate ``` Your project stracture should look like this:
{% hint style="info" %} In order for Python to know our src folder we need to set the path to src {% endhint %} ``` set PYTHONPATH=src ``` Now we need to include the CloudBeat modules in our **requirements.txt**: ``` cloudbeat-pytest cloudbeat-selenium pytest pytest-html pytest-metadata pytest-xdist python-dotenv webdriver-manager requests selenium uuid ``` To install it, use: ``` pip install -r requirements.txt ``` ## Implementing Cloudbeat Reporting We need to start by importing the Cloudbeat modules in our **confitest.py** file: ``` import uuid import pytest from selenium import webdriver from cloudbeat_common.models import CbConfig from cloudbeat_common.reporter import CbTestReporter from cloudbeat_selenium.wrapper import CbSeleniumWrapper ``` Then, create a custom config for CloudBeat reporter: ``` @pytest.fixture(scope="module") def cb_config(): """Prepare configuration class for further CB reporter initialization.""" config = CbConfig() config.run_id = str(uuid.uuid4()) config.instance_id = str(uuid.uuid4()) config.project_id = str(uuid.uuid4()) config.capabilities = {"browserName": "chrome"} return config @pytest.fixture(scope="module") def cb_reporter(cb_config): reporter = CbTestReporter(cb_config) return reporter ``` Finally, wrap our driver with the CloudBeat reporter: ``` @pytest.fixture() def setup(cb_reporter): driver = webdriver.Chrome() wrapper = CbSeleniumWrapper(cb_reporter) wrapped_driver = wrapper.wrap(driver) yield wrapped_driver driver.quit() ``` To test it locally, we can use several commands: ``` # run everything pytest # run parallel tests pytest -n 4 # run a single test pytest -v -s tests/test_login.py ``` After the test is finished, you should see a CB\_TEST\_RESULTS.json file which captured our steps.
## Creating a Python Pytest project in Cloudbeat Coming soon! # Creating Projects Projects are used to store test cases, environments and releases * Go to Projects under Project Tab in the bottom left:
* Click on add project, choose a name and select a framework:
* Choose a specific group that can view and access this project:
* You can start a project from scratch and add your files manually, or sync all your files by integratings with an existing git repository:
* By clicking on finish your new project will be created, and the groups associated will be able to view and access it, you can also assign new groups later on:
# Creating Environments Environments are a way of differentiating between stages of development, and set specific data for each stage, managing and running tests against multiple environments *Environments* allow you to run tests against multiple testing or production environments. It allows you to easily switch between different environments, tagging each test result with environment name for post-run results analysis. Additionally, it allows you to inject environment-related variables into the automation tests. ## **Environments screen** * Go to Environments under Projects and click on Add Environment:
This screen allows you to add new environments, set environment variables, modify and delete already defined records. Note that environment is defined on per project basis. Defined environment can be assigned to a Test Case, Test Suite or Monitor in Runtime Settings tab. ## Environment Variables Environment Variables allow to easily switch between different environment without a need to adjust automation scripts per selected environment. By utilizing environment variable in your automation tests code, you can seamlessly run the scripts against different environment with no changes to your code or configuration files. ### Define a new variable In order to define a new environment variable, select the relevant environment from the left-side environment list and then click on *Name* column in an empty row. Type the environment name and the value you want it to contain. Make sure to provide a unique environment variable name within the same environment. {% hint style="warning" %} Environment name can contain letters, numbers and \_ (underscore) character only. It should not include space or any other special characters. {% endhint %} * You can create different environments, and set unique data for each one:
## Getting Environment Variable's value in your test You can retrieve variables value of the specified environment in your test automation code. To retrieve the values, you need to use CloudBeat's Test Development Kit (TDK) suitable for your testing project language and framework. ### Retrieving Environment Variables value in Oxygen There are two options to retrieve environment variable's value in Oxygen. As the first option, you can use *"${\}"* syntax in most of Oxygen modules commands. For example, you can retrieve *BASE\_URL* variable's value to set your test's main starting page URL. Here is an example of opening a web page based on *BASE\_URL* environment variable: ```javascript web.open('${BASE_URL}'); ``` As the second option, you can access your environment variables using a special `env` variable inside your Oxygen script. The above example can be rewritten in the following way using `env` variable: ```javascript web.open(env.BASE_URL); ``` {% hint style="info" %} You can find more information on using Environment Variables inside Oxygen [here](https://docs.oxygenhq.org/advanced/environments). {% endhint %} * To use them in a test case, go to settings and pick your environment:
* To access their data, we simple use the env object, which will be referred to the environment selected, for example if we choose the TEST environment, env will be assigned to it:
# Creating Tests Cases Once you already have a test case that runs locally on your machine it is time to run it on CloudBeat. there is more than one way to create your tests, Here is how to create them on Oxygen framework: ### **Creating your first test case** * Go to Cases under Testing * Right-click the dashboard on the left panel and choose “Add Folder”
* Name your folder and confirm. * Now after the folder is created, it appears on the left panel under the dashboard, right click it and select the type of test case you wish to create - web or mobile. * ![](/files/nhFz218qNiFOSmboSpE0) ### Web/Mobile? What is the difference? Web tests and mobile tests are running on different platforms, for example - a web test can run on Chrome browser , Internet Explorer, Firefox. When creating a web case - ‘Browsers’ tab will appear , and there you can choose your platform to run and the current server you wish to run it on. A mobile test can run on certain devices - that use iOS operating system or Android , for example - Samsung Galaxy S7 , iPhone 8. When creating a mobile test - ‘Devices’ tab will appear, and there you can choose your platform to run and the current service provider / server you wish to run it on. ### Can a web test run on a mobile device? It sure can, make sure you use the correct capabilities (Use ‘browserName’ instead of ‘AppPackage’ and ‘AppActivity’) and choose a device from the ‘Devices' tab - or simply select an [App](/fundamentals/adding-apps) from the case settings. ### Filtering your devices list You can filter simply by clicking them and choosing from the list, here are the filtering options: * Device Status * Selected Devices * Device Names * OS (Operating systems) * Versions ### Create your tests in other frameworks Technically, your tests are being automatically created when you create your project (Whether you choose Git sync or just upload your project test) - if you want to see the tests you have created in CloudBeat you can see them in the Cases Screen. # Running Tests Cases ### **Execute a single test** You may execute your test from the cases screen by doing the following: * Inside the cases screen, click on the case you created. * You can decide who will receive notification for this case.
* You can schedule the case to run whenever you need.
* You can use data from a parameters file such as xlsx by uploading it.
Accessing the parameters in the script: ``` const email = params.email log.info(email) // 1@gmail.com ``` * Select the browser you wish to run the case on.
* Upload the script you wish to run.
* (Optional) - Go to settings and select [environment](broken://pages/-LuhbxJGIkshc9yWfyy0) and [releases](broken://pages/-Luhc-IajXZafUOIHNKT) you wish to run it on.
* Write details and upload relevant files for your case, and then click on Save Changes.
* Click on ‘Run now’ button which appears at the top right, The results will appear under Results tab.
* Click on the date, it will open the details about the case, on which browser it ran and it's steps:
* When the case opens a website, it also shows the requests happening behind the scenes:
* Now, let's open a failed case, we will see the failure reason, as well as all the steps lead to it, on which line it failed, and the screenshot of the failed step. Same as before, we can see the requests.
## **Execute a test suite** Running suites is exactly the same as running a single case, except here you can add multiple cases to run together. You may execute your test from the suites screen by doing the following: * Inside the suites screen, click on the suite you created.
* Under Cases or Tags, click on add cases:
* You may select which cases to run, by default it will run everything, save changes then run now:
* White the suite is running, you may see the progress:
* Finally, see the results by clicking on each case:
# Creating Tests Suites After we created several test cases, we can now group them under a suite and run them all together ### **Creating your first test suite** We create suites in the exact same way as a case, the only difference is choosing multiple test cases * Go to Suites under Testing * Right-click the dashboard on the left panel and choose “Add Folder” * Now after the folder is created, it appears on the left panel under the dashboard, right click it and select the type of test suite you wish to create - web or mobile
### Adding test cases to your suite 1. Select the suite you wish to work on by clicking it in the left panel 2. Click on the Cases or Tags tab 3. Click on ‘Add cases’ button above the cases list
Now select the cases you want to add, clicking on a folder will select everything in it
Click on Add & Close, then save changes # Running Tests Suites Running suites is exactly the same as running a single case, except here you can add multiple cases to run together. You may execute your test from the suites screen by doing the following: * Inside the suites screen, click on the suite you created.
* Under Cases or Tags, click on add cases:
* You may select which cases to run, by default it will run everything, save changes then run now:
* White the suite is running, you may see the progress:
* Finally, see the results by clicking on each case:
# Creating Releases Release life cycles are the process of developing, testing, and distributing a software product. It typically consists of several stages, which Cloudbeat makes it easy to track. * To add a new release & cycle, go to Releases under Projects:
* Right click on the release folder, and create a cycle:
* You can set the start date and the end date of the cycle, as well as describing it:
* Adding cases or suites to a specific release and cycle can be done in the settings tab:
# Adding Apps Adding an app sdk allows us to use it in a mobile case In this screen you’ll see a list of applications and maintain them in a higher level - what does it mean ? It means that if your application has gone through changes (app activity or package) you can manage all that in this screen - and you will not have to change it in each script that currently runs the app. ### First thing’s first! If you have no applications on the list - it’s time to create one - Click on “New App” button. In the new app window - type your app name and click “Add”. Now a new screen will open with the name you picked, and you may add a version to the app (optional). * To add a new app, go to Apps under Testing and click on New App:
* Now you can upload the APK and set the app details: ### Android Apps In order to configure your Android app you will need to provide 3 things: 1. App Package 2. App Activity 3. APK file If you don’t know the app package and app activity, simply open the app on your device and use an app called [APK info](https://play.google.com/store/apps/details?id=com.wt.apkinfo\&hl=en).
### IOS Apps In order to configure an iOS app - you must provide 2 things: 1. Bundle ID 2. IPA file Finding bundle ID can be done by doing the following steps: 1. Sign in to **iTunes** Connect. 2. Click My **Apps**. 3. Click on the **app** whose **Bundle ID** you want to **find**. 4. Click More and then click About This **App**. 5. Your **Bundle ID** is displayed and begins with [mobapp.at](http://mobapp.at/).
* To use it in a mobile case, open the case and go to settings:
### Editing/Delete an app Once your apps are created, you can simply edit their information by clicking the name of the application , and you will be forwarded to the edit page. If you wish to delete the app, in the app main page to your right, there’s a trash icon.
# Introduction to Cloudbeat sample projects A new Cloudbeat account includes some sample automation projects by default for you to try out and learn from and use as a reference. You can use any of these projects to do your very first Test and Suite executions in Cloudbeat. Each sample project has a corresponding Git repository in Cloudbeat's Github account and they are available for your use. You can navigate to each repository using links in Cloudbeat, and they are listed here for easy access as well. # Oxygen Cucumber project # Oxygen project # TestNG project coming soon # Integrations ### Integrations available: * CI/CD integrations - Jenkins, TFS, Azure Devops * Git integrations - All standard git service provider. * Bug reports integrations - Jira. ### CI/CD integrations: In order to integrate your CI/CD tool, you need to configure ‘CloudBeat CLI’ as a part of your build process. Here’s a video on how to do it: ### Git integrations: To sync with your Git service provider you need to provide the following: * URL - the address to your git project * Branch name - for example: ‘master’ * Name - your git username * Password - your git password This configuration needs to be done when first creating a [project](https://cloudbeat.atlassian.net/wiki/spaces/CBDOC/pages/220102667/Projects). ### Bug reports integrations: When a test case is finished with status failed - you may integrate it with a bug report system such as ‘Jira’. You need to do the following: 1. Go to your failed test results page by clicking it. 2. Select a failure reason from the drop down list on the top line of the test case. 3. On the top line you will have a ‘Jira’ button - click it. 4. Link the bug you opened in Jira in the ‘Link’ field. 5. Click ‘Add’ and the dialog will close. # 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. ### Installation: `npm install -g @cloudbeat/cli` ### Usage #### Execute a test case or suite: Following command will execute the specified Case or Suite, wait for the tests to finish, and will produce XML report in JUnit format: ``` cloudbeat-cli start --apiKey --apiBaseUrl [options] ``` If test execution succeeds exit code will be 0. Otherwise exit code will be 1. **Arguments**: * `testId` - Test id. * `testType` - Either `case` or `suite`. * `apiKey` - API key. Can be retrieved from the user profile in CloudBeat. * `apiBaseUrl` - CloudBeat API address. For SaaS it should be [https://api.cloudbeat.io](https://api.cloudbeat.io/). For on-premises installations consult your system administrator. **Options**: * `--project ` - Project name. If specified, then `` should specify case/suite name instead of an id. * `--tags ` - Specifies tags by which the tests will be executed. Will work only with Suite. * `-e, --env ` - Specifies environment to use for test execution. Environment should be already defined in CloudBeat for the project whose test is being executed. * `-a, --attr ` - Allows passing name-value pairs to test execution scripts. The passed data can be accessed via `attributes` property. E.g. `log.info(attributes)`. * `--release ` - Name of the release or version to be associated with the test result. * `--build ` - Name of the build to be associated with the test result. Requires specifying `--release` as well. * `--suffix ` - Report filename suffix to use. Must be either "time" or "id". * `--folder ` - Path to a directory where test results will be saved. If not specified, results will be saved in the current working directory. * `--silent` - Do not print test progress details. **Usage examples**: Execute Case by its id and pass environment id and test attributes: ``` cloudbeat-cli start case 70224 --apiKey AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEE --apiBaseUrl https://api.cloudbeat.io --env MyEnviroment --attr foo=bar,baz=qux ``` Execute Case by its name. Note that when executing tests by name, project name should be specified as well: ``` cloudbeat-cli start case "My Case" --project "My Project" --apiKey AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEE --apiBaseUrl https://api.cloudbeat.io ``` Execute tests marked with the specified tags in the specified suite. This will override any tags selected via CloudBeat UI: ``` cloudbeat-cli start suite 34984 --tags foo,bar,qaz --apiKey AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEE --apiBaseUrl https://api.cloudbeat.io ``` #### Get current test run status: `run-status` can be used for retrieving the status of a currently executing test: ``` cloudbeat-cli run-status --apiKey --apiBaseUrl ``` #### Get test result for specified test run: `run-result` can be used for retrieving the result data for a finished test: ``` cloudbeat-cli run-result --apiKey --apiBaseUrl ``` #### Update project artifacts: `sync` can be used for updating artifacts for the specified project using a zip archive. ``` cloudbeat-cli sync --apiKey --apiBaseUrl ``` **Arguments**: * `projectId` - Project id. Project type must support uploading artifacts as zip archives. * `artifactArchive` - Path to a zip archive containing the artifacts. * `apiKey` - API key. Can be retrieved from the user profile in CloudBeat. * `apiBaseUrl` - CloudBeat API address. For SaaS it should be [https://api.cloudbeat.io](https://api.cloudbeat.io/). For on-premises installations consult your system administrator. **Usage examples**: ``` cloudbeat-cli sync 53574 "C:\foo\bar.zip" --apiKey AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEE --apiBaseUrl https://api.cloudbeat.io ``` #### Additional general options (work with all commands): * `-f, --failOnErrors ` - Controls whether to return non-successful exit code on errors or not. # Jenkins Running your tests in CloudBeat from Jenkins pipeline You can easily trigger and run tests in CloudBeat inside your Jenkins pipeline using the guide below. CloudBeat takes the hassle of parallelizing and scaling your tests in Jenkins, grouping test results and allowing to see the test reports inside Jenkins. ### Adding CloudBeat's API Key in project parameters We recommend to use Project Parameters to store CloudBeat's API Key. This will allow to centrally managed CloudBeat related credentials and share the API Key between multiple CloudBeat CLI invocations. To add CloudBeat's API Key as project parameter, complete the following steps: * Go to configure page of your current build. * In *General Tab* , tick '*This project is parametrized*'. * Fill in the name of the key, and value. Below is an example of specifying CloudBeat's user API Key: ![Name is the key , and default value is the API key.](/files/-LumMWwIU9SXOLE8ZOEM) {% hint style="info" %} **NOTE:** API Key can be found in My Settings -> Security screen. See [General Settings for more details.](/settings-and-administration/managing-my-profile#general-settings) {% endhint %} ### Running your tests as part of the Build In order to trigger your tests from Jenkins, you will need to use CloudBeat CLI. You need to add the below steps right at the point where you want your tests to be executed. Go to your Jenkins build and add **two** *Execute Shell* build steps:
Add the following Command in the **first** added step in order to install CloudBeat CLI as NPM module (Node.js installation is require prior to this step execution): ``` npm install @cloudbeat/cli -g ``` In the **second** added step, enter CloudBeat CLI `start` command with related arguments. Here is an example of CloudBeat CLI command that runs a specified test case: ``` cloudbeat-cli start case 70224 --apiKey AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEE ``` {% hint style="warning" %} Node.js 16 or above must be installed in your Jenkins or Docker environment before running *npm install* command. {% endhint %} {% hint style="info" %} You can find more details on various CloudBeat CLI commands and argument [here](/features/integrations/ci-cd-tools). {% endhint %} ### **Additional Parameters** Exit code can be controlled with `--fail-on-errors` (true or false). Default is true. For example `--fail-on-errors=true` You can see full error using debug mode `--debug` (true or false). Default is false. For example `--debug=true` ### Test result reporting In order to get a test report in Jenkins when the test run is finished, you need to add the following post-build action: ![CloudBeat CLI will generate JUnit XML based result file which will be processed by this post-build action.](/files/-LumTx7k8nWdw51pXCZ3) You can also see the full test report inside CloudBeat UI, which will include test summary insights, detailed execution steps, performance metrics, various logs and AI-driven failure root-cause analysis. # Azure DevOps Integrating Azure with CloudBeat enables automated cloud testing within your CI/CD pipeline. It streamlines test execution, provides detailed reporting, and ensures faster feedback. ### Prerequisites In order to run a test case, we need 3 things: Cloudbeat API Key, test case id and test type. ### Cloudbeat API Key To find your api key, go to Account > Settings > Security or follow this link: ### Test Case ID To find a case id simply open cases and open the case you want to run.
### Test Type You can choose between a case, which is used for a singular test, or suite for multiple tests. ## Azure Pipeline **Start by creating a new pipeline in Azure** * **Log In and Navigate** * Go to [Azure DevOps](https://dev.azure.com/), log in, and open your project. * **Go to Pipelines** * Click on **Pipelines** in the left-hand menu, then choose **New Pipeline**. * **Select Source Repository** * Choose the repository where your code is stored (e.g., Azure Repos or GitHub). * **Choose the Classic Editor** * When setting up the pipeline, select **Use the Classic Editor** instead of YAML. * **Configure Pipeline Settings** * Set the pipeline name (e.g., `Cloudbeat-cli Run Test Example`). * Under **Agent Pool**, choose **Azure Pipelines** and select the **Agent Specification** (e.g., `ubuntu-22.04`).
* **Select the Repository Source**: * In the pipeline editor, under **Get Sources**, click the edit icon. * Choose **GitHub** (or another repository type based on your project). * **Authorize the Connection**: * If GitHub is selected, ensure it’s authorized using an access token. Click **Change** to modify or reauthorize if necessary. * **Set Repository and Branch**: * Repository: Select the specific GitHub repository (e.g., `oxygenhq/docs`). * Default Branch: Specify the branch to build from (e.g., `refs/heads/master`). * **Adjust Source Settings**: * **Clean**: Set to `false` (default) to avoid cleaning the workspace before building. Change to `true` if a fresh workspace is needed for every run. * **Tag Sources**: Choose whether to tag the repository: * **Never**: Don’t tag builds (default). * **On Success**: Tag only successful builds. * **Always**: Tag every build. * **Report Build Status**: * Check the box to report the build status back to GitHub.
## Define Variables You can create variables to store data such as API keys and other data to use across the tasks.
## Add Agent Job First we need to add a command which will install the cloudbeat cli ### Install Cloudbeat CLI Add a command line task, name it "Install @cloudbeat/cli" Add the script: `npm install -g @cloudbeat/cli`
### Run Test Case To run our test, we need to add another command line and pass in the test type, id, and api key: cloudbeat-cli start testType testId --apiKey=apiKey But since we defined our variables, we can add this to the script: `cloudbeat-cli start $(cbTestType) $(cbTestId) --apiKey=$(cbApiKey)` when the test ends, it will create an JUnit XML results file ### Publish Test Results Lastly we need to publish the results. Add another task called "Publish Test Results":
## Run Pipeline Press on Queue and Run
Inside Cloudbeat, you will see the test case starting
After it's finished, you can see the results by following the link under Publish Test Results:
# Cloud Providers # Genymotion coming soon # Applitools coming soon # Perfecto ## Overview With CloudBeat test orchestration and analytics platform, you can seamlessly manage, run, scale and analyze automated tests. CloudBeat works with many popular test automation frameworks and Cloud Providers, among them Perfecto. This guide will explain how to configure and run tests on the devices available in your Perfecto account. The guide assumes you already have both CloudBeat and Perfecto accounts. ## Perfecto Account Configuration In order to connect your Perfecto account, you can either provide your Perfecto security token (can be found in your Perfecto account settings) or your Perfecto username and password (not recommended). Log in to your CloudBeat account and go to Settings -> Integrations -> Perfecto. Select your preferable authentication method and enter the corresponding details. Your new settings will be automatically saved. ![Perfecto configuration page](/files/-M6MQiUzYHtw9gx4l8Nm) ## Accessing Your Perfecto Devices After you have set your Perfecto credentials in the previous step, you can now run your CloudBeat tests on the devices available in your Perfecto account. In order to select Perfecto devices, open the test you want to run on these devices and go to Devices tab. In the devices list, you will see your Perfecto devices under “Perfecto” category. You can mix Perfecto and other devices available in your CloudBeat account. Next to each device, you will see the current device status. To add your Perfecto devices into the mix, just select the desired devices and press “Save” button. Appium capabilities will be automatically generated based on the device specifications and will be injected into your test script. ![](/files/-M6MQxIJEs2FoCAKSU3b) # Supported Frameworks ## Frameworks supported: CloudBeat supports 4 frameworks - yet develops it’s own framework: * [Oxygen](http://docs.oxygenhq.org/) (as a CLI or an IDE) - make sure you try that out for an easy approach that requires little to no knowledge in coding. * [Java + Cucumber](https://cucumber.io/) - this framework has the simple advantage of writing your tests in a certain method - while the person who develops in Java - makes it read the text written in the test - and runs it as an automation test. * [Java + TestNG](https://testng.org/doc/) - this framework is the most popular framework in the testing automation world. * MSTest - this framework is supported by Microsoft and written most of it in C#, it is open source and can be also used for unit testing. ### Oxygen Project [How to create a new Oxygen Project.](https://cloudbeat.atlassian.net/wiki/spaces/CBDOC/pages/220299265/Oxygen+Project) ### Cucumber + JAVA Project [How to create a new Cucumber + Java Project.](https://cloudbeat.atlassian.net/wiki/spaces/CBDOC/pages/220069930) ### .NET Project [How to create a new .NET Project.](https://cloudbeat.atlassian.net/wiki/spaces/CBDOC/pages/220200986/.NET+Project) ### TestNG Project Coming soon. # Data-Driven Testing In order to run the same test with different values, you can attach Test Data (parameters) file to your test. You can upload or change your test data in Parameters tab in Test Case or Test Suite screens. **In the following example, you can see a parameter file that the test called 'Web Test' will use.** ![Click the picture to view example for parameter file](/files/-LumBBPtANjAxAL_3IN3) You can control how parameter file is being read by selecting one of the following options in "Fetch parameters" field of "Settings" tab in Test Case or Test Suite screens: * *Sequential* - select the next test data row sequentially per each test iteration * *Random* - randomly select the next data row per each test iteration Using your test parameters in your test scripts is framework specific. Select your framework below to learn how to access CloudBeat-stored test data in your code: * [Oxygen](/features/data-driven-testing/ddt-oxygen) * [TestNG](broken://pages/-Lulcgr7O7sc0YdH4wL6) * JUnit 5 * MS Test * Cucumber (with JUnit 4) # DDT - Oxygen Framework CloudBeat's runner will automatically bind the test data defined in Parameters tab of your Test Case or Test Suite and will pass it on to the underlying Oxygen framework ### Using parameters from an external file In order to replace a constant value with a test parameter in Oxygen Framework, we can use the **params** object, which is assigned to the parameter file and contains it's values. For example here is a parameters file with 2 values:
Our parameter name is “email” and the value is “<1@gmail.com>”, the following example will perform type action in your Oxygen script and will replace "email" parameter with "<1@gmail.com>" value: `web.type(“id=email”, params.email);` ### Using parameters from environments Additionally, Environment variables can be created and be used for different environments. For example, here we have TEST and DEV, we create a "url" and "user" parameters and assign their values to "" and "testo" in our TEST environment:
To use them, we simply specify which environment we want to use in our case/suite/monitor:
After that, to access them in the script we use the **env** object which is assigned to our chosen environment, then access the values by using the following syntax: ``` web.open(env.url) web.type('id=username', env.user) ``` For more info see: {% content-ref url="/pages/xQdlQPTzRdNysqsQ02IA" %} [Creating Environments](/fundamentals/creating-environments) {% endcontent-ref %} # What is CloudBeat Synthetic? ![](/files/-MRBD5udShMjkw-V3chu) **Your All-In-One Production Guard** Cloudbeat synthetic, a revolutionary synthetic monitoring platform that harnesses the full potential of existing test automation platforms. With a simple connect to the R\&D GIT repository you are now finally able to monitor your user's digital experience on top of web pages, mobile applications, API traffic using any automation that exists in your R\&D department. Using Cloudbeat synthetic you can: * Create a consistent baseline of your user experience * Be alerted of fluctuations in response time * Detect geographic performance abnormal response time or availability * Track your entire digital assets traffic and issues in production * Set specific SLA for different business transactions * Notify and alert different teams regarding relevant issues in production * Get ongoing statistics and metrics on the scenario and transaction levels **Utilize your R\&D tests on top of production** Connect to any existing test automation scripts in your R\&D and utilize them for your synthetic monitoring. Using the knowledge and experience of R\&D professionals * Connect to GIT repository * Get Reflect code presented as executable Suites * Designate specific suites for your synthetic monitoring. * Execute Web, mobile, API, desktop automation, SMS messages * Get full root cause analysis of your test results including logs, screenshots, waterfall, transaction response time and failure analysis. * Ongoing performance and availability of the inspected transactions Note: you can also Create your own web and mobile scripts using a powerful, state of the art, recorder provided by CloudBeat. ![1. Connect to any existing automation 2. Set browsers or devices 3. Monitor your production](/files/-MRBUJiqbY4gjlzb4NZZ) **SaaS or On-Premise** Flexible deployment of the synthetic monitor allows you to set a monitor on-premise or in the cloud. Synthetic monitor comes with different flavors: * Full on-premise installation (Local server and agents) * Hybrid installation (SaaS server and local agents) * Full SaaS (Server and cloud agents) Simply select the desired configuration and start monitoring. **Cross region, device and browser** CloudBeat synthetic allows you to monitor any browser or device from any geo location in the world. Simply connect your synthetic to your favorite cloud farm and you will instantly be able to execute your synthetic monitor from any location and device or browser globally. * Any browser or device farm (Sauce labs, Browser stack, perfecto mobile and many more) * Any browser version (Chrome, Firefox, Safari, Edge and more) * Any device (Android, IOS, Tablets, Note) * Any geo-location in the world **DevOps continuous deployment** You may connect your synthetic monitor to any of your DevOps engines and synchronize your synthetic monitoring with the continuous integration and continuous deployment process. This will allow you to add canary testing and an extra layer of validation on your deployment. * Any DevOps engine using a CLI tool (Jenkins, Circle CI, GitHub, Azure DevOps and many more) * Pre merge, Staging, Canary and any other pre or post deployment. **Transaction based** You can provide clear business transactions that can be monitored separately and analyzed to get detailed understanding of the expected user experience. The transactions are displayed as steps and can be drilled to the waterfall level. ![Transaction based monitoring with a waterfall per transaction](/files/-MRBmCKDAPh5duDQmn9I) **Use your favorite coding for your tests** Use the most common coding frameworks for test automation in Java, C#, JS, Cucumber, API and others: Here is a list of the frameworks supported (Postman and Cypress.io coming soon) ![](/files/-MRBD5ugXK1ugt06VNly) 1. **Connect to any existing automation 2. Set browsers or devices 3. Monitor your production** ![Connect to GIT repositort to connect test automation](/files/-MRBD5ujf-teDTL9UP_K) ![Select Any browser or device](/files/-MRBSHk1P-lTJky2OCAB) ![Monitor the tests in production](/files/-MRBD5uiVN54UXXo4-br) ![Get root cause analysis of results](/files/-MRBD5ukynYpd1m8vEcz) ![Oxygen IDE- Create your web, mobile, API, desktop automation](/files/-MRBD5ulhJRri6pzqo50) ![Generate execution reports](/files/-MRBD5um_AIoTwPRSqb0) # Creating your first monitor **Test project configuration** In order to create a monitor, you need to have some tests ready inside a project. For further information on how to create a project or adding tests to a project, please refer to[ projects](https://docs.cloudbeat.io/references/projects) section and the [Test Cases](https://docs.cloudbeat.io/references/test-cases) section in this tutorial. **Configure the monitor** Once you set up a test project and added test cases to the project you may create a new monitor. Simply click on the monitors menu item ![](/files/-MRC1BJ8LU-9ry_q1AN1) Now click on the "Add monitor" button and fill in the monitor name in the dialog box that appears. fill also the name of the test project you created in the first dialog box and the type of monitor (Web or Mobile) in the second dialog box. Note: you can set a web or mobile monitor, so tests that are attached to the monitor should be from the same type. ![Add monitor button](/files/-MRC0xp9OE9dyQCA5FcX) ![](/files/-MRC2EOUu2aXK98l0nu1) After you click Add, the monitor configuration page opens. Here you can set the following details on the monitor configuration * General- Set Module name, test mode, performance threshold for te test and description * SLA- Set General and transaction SLA threshold * Reports & Alerts- Set the groups that get the alerts and reports. you can set different types of alerts and reports for each group * Browsers/Devices- select the devices or browsers that will be used in the monitor * Cases- select the cases that will be used in the monitor. you can select one or more for each monitor. * Schedule- Set time schedule for the monitor to run. you can select Every several minutes or per day or a specific time * Settings: Similar to suites settings. here you can define the runtime settings, versions, iterations and other runtime options. ![](/files/-MRC9P12C0qqX3ehR5Pk) # Review general monitor results **General monitor dashboard** After you set the monitor, it will be executed automatically according to the time frames you scheduled for it. The new monitor should appear in the Main dashboard monitor page ![Monitor main dashboard page](/files/-MRCLn2eY9B_TlQnL3k1) The general monitor dashboard will display the Availability and performance of all the available monitors. If you want to review a specific monitor simply click on it to drill down to the results. # Review specific monitor dashboard Once you click on a specific monitor, the results of that monitor will appear on the screen. ![](/files/-MRCOlav7l8ryOVH9QeL) In addition to the information seen in the general dashboard, you will see the following information: SLA STATUS- Displays all the SLA that were defined for this monitor and the values that were monitored according to the SLA criteria ![SLA results in the monitor](/files/-MRCQI0wVjUeuEO_xyHR) RECENT FAILURES- Displays the failures that were found during the execution of the monitor. each failure can be drilled to see the full execution logs, screenshots, steps and any other information. ![Recent failures table](/files/-MRCR4Nbsl3o0zx5CHQv) TRANSACTIONS SUMMARY- a full breakdown of the transactions monitored in all the test cases and the values they received ![](/files/-MRCRcqxOm8fw7U9qp51) # Create SLA **This option allows you to create an availability and performance test for SLA.** **(Service Level Agreements)** Head over to Monitors and select SLA ![](/files/-MSXyat5OirYLjTeznIv) **Let's create a general SLA** Click on **( + ) New General SLA** on the right side ![](/files/-MSY-xwcZCAiHOWp-SBT) Choose your SLA goal, whether availability or performance, SLA scope, whether a general monitor, a specific test case, or per transactions inside a test case. To add a specific case, head over to cases and click on **+ Add Case** and choose your case. ![](/files/-MSYAL8lyYn9T47885am) {% hint style="info" %} **You can find the transactions inside your test case script** {% endhint %} ![](/files/-MSYOLSW_PhGutaiLF4I) # Create Reports & Alerts **This option allows you to send reports and alert a specific group about the test results.** Head over to Monitors and select reports & alerts ![](/files/-MSXgwEAwHSgkpziEMJq) **Now let's create a group for summary report** Click on **( + ) Add Group** on the right side ![](/files/-MSXj04z_kvELGFEbHhU) You can choose the group which you want to receive the summary reports, and also the frequency of the reports which can be set to daily, weekly, monthly. **Finally, let's create alerts** Once again, click on **( + ) Add Group** on the right side ![](/files/-MSXmJYbLnhkCVb2HrFf) Choose a group which will receive the alert notification, and the events which will trigger the alert. # Changing Runtime Setting **Runtime is used to define iterations, parameter usage, environment settings and other options which include re-running a failed test and collecting browser logs.** Head over to Monitors and select Runtime ![](/files/-MSYPoBdw1E0B5Fiw8TK) We can keep the test as a single iteration, or set it to a specific number by selecting **Multiple iterations** option and selecting the desired number of iterations. We can also match the number of iteration to the number of parameters available, by selecting **Use all parameters** {% hint style="info" %} **Your test script must have a parameters file attached to it in order to use them** {% endhint %} To add parameters go to your test script and select parameters then simply upload your file. ![](/files/-MSYS9sctpp7n9q48o7L) We can also choose a specific environment, if we don't have one yet, we can simply create one by clicking on **Manage Environments** which will take us to the environments page ![](/files/-MSYTkNNQvIlW9qlovXg) # Run Monitors **To run a monitor simply click on the menu at the top right in your monitor screen:** ![](/files/-M_0Zml9X8IlS5MKX2A9) **You can also set a schedule for your monitors which will make them run automatically.** Simply set the time in which you want the monitor to run and click on save changes. ![](/files/-M_G4tJ4JsgrE46tLcG9) Go back to your monitors page and check the results. ![](/files/-M_G54oyDNB1O9MUA70a) # Maintenance Maintenance Windows allows you to set a maintenance schedule which will stop all monitor activity during the specified time, and automatically continue to run afterwards. **What is a maintenance?** It's a process which contains software preparation, problem identification and finding out about product configuration management. • The problem identification process includes checking validity, examining it and coming up with a solution and finally getting all the required support to apply for modification. • The platform migration process, which is used if software is needed to be ported to another platform without any change in functionality So while these processes are active, active monitor tests may interfere with them, that's where Maintenance Windows comes in handy and provides the option to stop the chosen monitor tests at any desired time and resume them when needed. **Maintenance schedule has several options:** • Once, when you have a sudden and critical issue. • Weekly and monthly for scheduled occasions such as software updates. **To set up maintenance head over to the Monitoring section and click on Maintenance:** ![](/files/-M_QT8Flpg8TbKUagsD7) **Click on New Window, give it a meaningful name, and choose your desired frequency and save:** ![](/files/-M_QUPnF233q1sJjLCL5) **After saving, your preferences the maintenance will appear and you'll be able to modify it or delete it under ACTIONS** ![](/files/-M_QUtCf3SCG65g1kLuv) # Incidents Incidents allow you to track your monitors and find problems based on your desired conditions To create Incidents for your monitor, head over to: **Monitoring -> Monitors -> Your Monitor -> Edit -> Policies -> ( + ) New Policy** ![](/files/-M_QVYxCb-atsCNQUR_q) ![](/files/-M_QVeimkP19prJ9e72m) ![](/files/-M_QW_N4vt_lOP0IBYzw) ![](/files/-M_QYjIzSjQMmu56vB8X) Range type is based on your last number of **runs / minutes / hours / days** Metric will determine your **monitor / instance availability** based on your desired percentage Incident Severity will alert based on the severity, **Unknown (No alerts) / Minor / Critical.** {% hint style="info" %} To set alerts, head over to: **Reports & Alerts -> ( + ) Add Group** {% endhint %} ![](/files/-M_QbJuGsNuBdiO1Whng) Resolve Automatically **will stop the incident** if no problems were founds. ![](/files/-M_QajIV3Fm1f_beB79G) # Full Monitor Test - Example ### **First let's make sure we have our test case ready.** for this example I've created a simple web script which includes transactions. ![](/files/-MSmIgIwddm8EY7Hzk0Z) {% hint style="info" %} Environments are optional, but for this example I've included one with a single value of url, for better practice {% endhint %} ![](/files/-MSmJH6E5xw7-U1n4cpF) Now we are ready to create our monitor, let's head over to Monitors and click on **Add Monitor** ![](/files/-MSmLETJImX0DvcpYvKb) Select the project which includes your test scripts, and the test mode, **Web** or **Mobile** ![](/files/-MSmLdnj_rWet6Ng6xvA) ### **Now let's define our browser and choose our test case** ![](/files/-MSmMynywYLEnyEwCEqy) Click on browsers and choose your desired browser ![](/files/-MSmNSDfAy1WZTnhmdKU) Click on cases and add your test case ![](/files/-MSmNiyDSd7M786hJt9g) ### **Now let's define our SLA settings and set reports & alerts** Click on SLA and then click on **( + ) New General SLA** Choose your SLA goal, whether availability or performance ![](/files/-MSmPNR1kyTVkMi0qvXI) You can set the SLA scope to monitor over the cases which you added in the previous step, or choose a specific test and transaction ![](/files/-MSmR3k81iM8T6Wna8bK) {% hint style="info" %} **Transactions will appear after the monitor has run at least once** {% endhint %} Click on save and head over to reports & alerts, then click on **( + ) Add Group** Choose your desired group and the frequency ![](/files/-MSmRlMMCzmoEy6ZqVrr) You can do the same for alerts if you wish ### Finally let's define our runtime settings and schedule head over to runtime and set the environment to QA, which we created earlier, and configure the runtime as you desire, for this example I will keep it as a single iteration. ![](/files/-MSmT4DBQ3p7m-0eHedf) {% hint style="info" %} If you're using parameters in your case, make sure they are uploaded correctly to avoid trouble {% endhint %} And for the last step, go to schedule and set your desired schedule ![](/files/-MSmUPS_qLvJBIajc19v) #### Click on save changes and we're all set, come back after 10 minutes and see your results! ![](/files/-MSmUqypO8oR4NyzhTqW) ![](/files/-MSmUzmoQNditYVRrYUF) # Managing Notification Groups ### **Creating a group** In order to create a group - click on the “New Group” button on the top right, provide a group name in the dialog, and click “Create” in order to continue, or “Cancel” to cancel the group creation process. ### **Permissions management** Each permission is shown in the same row as the group name, by default, the “Administrators” group will be granted with all permissions possible. Available permissions: * Edit Projects. * Edit Monitors. * Edit Tests. * Run(Execute) Tests. ### **Granting a permission** In order to grant a certain group a permission, simply tick the permission’s checkbox that shares the same row as the group. # Managing Permissions ### **Creating a group** In order to create a group - click on the “New Group” button on the top right, provide a group name in the dialog, and click “Create” in order to continue, or “Cancel” to cancel the group creation process. ### **Permissions management** Each permission is shown in the same row as the group name, by default, the “Administrators” group will be granted with all permissions possible. Available permissions: * Edit Projects. * Edit Monitors. * Edit Tests. * Run(Execute) Tests. ### **Granting a permission** In order to grant a certain group a permission, simply tick the permission’s checkbox that shares the same row as the group. # Managing Users ## **Users Screen** The users screen is where you can add new users , delete them, and assign them into groups. ### Adding a user In order to add a user - you must first click ‘New User’, once you’ve clicked it, a window will pop up and you will need to provide a valid email address of the user, and the invitation message (optional). Once you’re done, click ‘Invite’ to send, or ‘Close’ in order to cancel. ### Deleting a user In order to delete a user - simply click the ‘x' that is aside the user’s name - after clicking - confirm the action by clicking ‘Yes’ or ‘No’ if you wish to cancel your action. ### Assigning a user to a group Once you have users in your list, in the same row as the user to the far right there is a ‘+' icon, in order to assign, click that icon, and select an available group from the list, click ‘Add’ to assign or 'Cancel’ if you wish to cancel your action. Have no groups in your list? follow the [instructions to create groups](/settings-and-administration/managing-notification-groups). # Managing Account ## **Account Screen** The account screen is where you could edit your account details. ### Edit account details Simply edit your account details by typing the details in the following fields: * Name * Address * Country * VAT Number When you’re done editing your details, click ‘Save changes’ to save, or ‘Cancel’ to cancel. # Managing My Profile ## **General settings** **API Key** - used for integrations / different platforms to run your tests, this key is generated per profile. ### **Edit your password** In order to edit your password - provide your old password in the “Current Password” field, and type your new password in the “New Password” field , and then confirm it in the field below. # Active Runs ## **Active test screen** This screen is the active running tests screen that contains status of all tests that are currently active from all projects (permission wise).
### Active tests table: The active runs table shows information and lets you perform basic actions to your currently active test cases/suites. * Date - shows the date and time of the test execution. * Test Name. * Status - Pending , Initializing, Running. * Duration - The amount of time to execute from beginning to current time. * Executed By - The user who executed the test. * Actions - if you want to stop the test - “Stop Now” is an action to stop your currently running test case/suite. ### Detailed progress If you want to get the detailed progress of a certain test case/suite, simply click the date on the certain row and it will direct you to the specific progress of running test. # Test Results ## **The test results screen** This screen is the main result screen that contains results of all projects (permission wise) and filter them, getting the specific results you were looking for. ### Filtering 1. Date range filters by: * Last week * Last 30 days * Last month * Last year 2\. Project filters by the project's name. 3\. Releases filters by release. 4\. Status filters by: * Passed * Failed
### Results table: The results table shows information about your test cases history run regarding the filters you have chosen: * Date - shows the date and time of the test execution. * Status - Failed or Passed. * Test Name. * Project’s Name. * Duration - The amount of time to execute from beginning to end. * Release/Cycle - If the test have been assigned to a certain release or cycle. * Executed By - The user who executed the test. ### Detailed results If you want to get the detailed results of a certain test case, simply click the date on the certain row and it will direct you to the correct result. ### Case information If you want to edit or get more information about history run of a certain test case, click the test case’s name. # Projects ### Adding a project: On the top left screen - click on the ‘Add Project’ button and follow the following steps that fits your project.
### Oxygen Project [How to create a new Oxygen Project.](/references/projects/oxygen-project) ### Cucumber + JAVA Project [How to create a new Cucumber + Java Project.](/references/projects/cucumber-+-java-project) ### .NET Project [How to create a new .NET Project.](/references/projects/.net-project) ### Java TestNG ### Java JUnit 5 ### Kotlin TestNG ### Kotlin JUnit 5 ### MSTest - Binaries ### Playwright ### Cypress ### Postman ### Rename a project: Right click a project name , choose ‘Rename’ and simply type the name you wish the project to have.
### Delete a project: Right click a project name and choose ‘Delete’.
# Oxygen Project ## Oxygen Project Step 1 - Select a name for the project and on the second field choose ‘Oxygen’. Step 2 - Select the group of users to have access to this project. Step 3 - (Optional) - provide git information in order to have auto sync with your git project. # Cucumber + Java Project ## Cucumber + JAVA Project Step 1 - Select a name for the project and on the second field choose ‘Cucumber + Java’. Step 2 - Select the group of users to have access to this project. Step 3 - Project files - Options available: * upload project files. * Sync with CI server. * Sync with your Git project. Step 4 - First field - Command “mvn test”, Second field - Cucumber options “--glue classpath:io.cloudbeat.cucumber.glue.other” Step 5 - Confirmation : wait till the bar finish loading. # .Net Project ## .NET Project Step 1 - Select a name for the project and on the second field choose ‘.NET (SDK-STYLE) Binaries’. Step 2 - Select the group of users to have access to this project. Step 3 - Project files - Options available: * upload project files. * Sync with CI server. * Sync with your Git project. Step4 - Assembly Names Step 5 - Confirmation : wait till the bar finish loading # TestNG Project Setup Description on how to prepare a TestNG project to be used in CloudBeat #### Plugin Integration Add the `cb-framework-plugin-testng` plugin to your project. For Maven base projects, this requires adding plugin repository and the plugin dependency. {% hint style="info" %} Gradle based projects are not currently supported . {% endhint %} First add the repository to your `pom.xml`: ``` jitpack.io https://jitpack.io ``` And add the plugin dependency itself: ``` com.github.oxygenhq cb-framework-plugin-testng 0.10.1 ``` In addition, if running multiple parallel tests is required, maven surefire plugin with version equal or higher than 2.22.0 should be added to the `plugins` section: ``` org.apache.maven.plugins maven-surefire-plugin 2.22.0 ``` #### **Code Level Integration** Add plugin listener to your test class and extend the test class from `CbTestNg` ``` @Listeners(io.cloudbeat.testng.Plugin.class) public class SeleniumTest extends CbTestNg { } ``` #### Working with Selenium When using Selenium it might be beneficiary to be able to take browser screenshots in case of failures. **Providing WebDriver instance** ``` import io.cloudbeat.testng.CbTestNg; import org.openqa.selenium.WebDriver; import org.openqa.selenium.remote.DesiredCapabilities; public class SeleniumTest extends CbTestNg { @BeforeClass public static void setUp() { DesiredCapabilities capabilities = ... // User capabilities // For default web browser initialization based on CloudBeat capabilities setupWebDriver(); // For default web browser initialization based on user capabilities and CloudBeat capabilities initWebDriver(capabilities); // For default mobile driver initialization based on CloudBeat capabilities setupMobDriver(); // For default web browser initialization based on user capabilities and CloudBeat capabilities initMobDriver(capabilities); //Or just setup your own driver WebDriver driver = ... // Your driver initialization setupDriver(driver); // Set up driver this.driver; // Created driver } } ``` **Custom steps** In order for CloudBeat to produce nicer repots, `startStep` and `endStep` methods can be used to designate test actions ``` import org.testng.annotations.Test; public class SeleniumTest extends CbTestNg { @Test public void Test1() { startStep("Step"); startStep("Inner step"); endStep("Inner step"); endStep("Step"); } } ``` # Reports ## The reports screen This screen is where you can find certain reports by either Release, Project , or Environment. ### Release Report 1. Select a project from the list in the drop-down list, if you haven’t any projects, make sure to check how to create one [here](/references/projects). 2. Select range of time for the report in the list to the right. 3. Click on “Show Report” Now you will see a full detailed report as “Pie chart” , and if you scroll down a bit you will get fully detailed results per releases / cycles, and once you click the certain cycle - you will get a list of tests that was executed under that cycle with their status, passed or failed. ### Project Report 1. Select a project from the list in the drop-down list, if you haven’t any projects, make sure to check how to create one [here](/references/projects). 2. Select range of time for the report in the list to the right. 3. Click on “Show Report” Now you will see a full detailed report as “Pie chart” , and if you scroll down a bit you will get fully detailed results per releases / cycles, and once you click the certain cycle - you will get a list of tests that was executed under that cycle with their status, passed or failed. ### Environment Report 1. Select a project from the list in the drop-down list, if you haven’t any projects, make sure to check how to create one [here](broken://pages/-LuhbxJGIkshc9yWfyy0). 2. Select range of time for the report in the list to the right. 3. Click on “Show Report” Now you will see a full detailed report as “Pie chart” with environment data as well. # CloudBeat Playwright Integration - Migration Guide This guide describes the changes required to your Playwright project in order to support the latest CloudBeat execution engine. These updates enable **individual test execution** (instead of whole-spec only), **nested folder support**, **improved result reporting**, and **greater overall flexibility**. *** ### 1. Update `@cloudbeat/playwright` to v2.1.0 Update the package to the latest version using one of the following commands, depending on how it is installed in your project: **Regular dependency:** ```bash npm install --save @cloudbeat/playwright ``` **Dev dependency:** ```bash npm install --save-dev @cloudbeat/playwright ``` After updating, verify your `package.json` reflects version `2.1.0` or higher. If you are using Git, make sure to commit the updated `package-lock.json` as well. *** ### 2. Update `@playwright/test` to v1.56.0 or Later *(Optional)* This step is optional but **strongly recommended** if your test suite contains tests with **Hebrew or other special characters** in their names (e.g. accented letters, symbols, etc). Upgrading ensures more reliable test execution in those cases. **Dev dependency:** ```bash npm install --save-dev @playwright/test@1.56.0 ``` *** ### 3. Ensure Commands Run Successfully on an External Server When a project is uploaded manually or synchronized from Git, CloudBeat executes the following two commands on its server: ```bash npm ci npx -y playwright test .spec.ts --list ``` **Both commands must complete successfully in a clean, external environment.** To verify this, make sure your project: * Does **not** rely on any files that only exist on your local machine (note: dynamic imports inside test bodies are fine, as long as `npx -y playwright test .spec.ts --list` completes successfully - that command does not execute the tests themselves) * Does **not** depend on packages from **private registries or repositories** (unless the server is configured to access them) * Has a valid and complete `package-lock.json` committed to the repository (required by `npm ci`) * Has all required environment variables documented, with safe defaults where possible Test this locally by cloning your repo into a fresh directory and running both commands from scratch. *** ### 4. Remove Line Breaks from Test Titles Test titles must **not contain line breaks** (`\n`). Tests with multi-line titles will not be executed correctly. This issue most commonly occurs when using template literals (backtick strings) in JavaScript/TypeScript. Make sure all test titles are on a single line. **❌ Incorrect — contains a line break:** ```js test(`user can log in with valid credentials`, async ({ page }) => { // ... }); ``` **✅ Correct — single line:** ```js test(`user can log in with valid credentials`, async ({ page }) => { // ... }); ``` Review your entire test suite for any `test(...)` or `describe(...)` blocks where the title string spans multiple lines, and flatten them. *** ### 5. Manually Added Cases Will Be Cleared on Project Re-upload/Re-Sync > ⚠️ **Important:** Any test cases that were manually added to suites in CloudBeat will be **removed** when the project is re-uploaded/re-synced first time. After completing the migration and re-uploading your project, make sure to **re-add test cases** to their respective suites. *** ### Summary of Required Changes
#ChangeRequired
1Update @cloudbeat/playwright to 2.1.0+✅ Yes
2Update @playwright/test to 1.56.0+⚠️ Optional (but highly recommended)
3Ensure npm ci and --list commands succeed on a clean server✅ Yes
4Remove line breaks from all test titles✅ Yes
5Re-add manually added cases after re-upload/re-sync⚠️ Informational
# CloudBeat Playwright Agent - Docker Deployment Guide *** ### 1. Overview The deployment consists of two containers: * **cb.controller.playwright** — The CloudBeat test controller and Playwright runner. Connects to the CloudBeat Gateway, executes tests, and reports results. * **playwright-browsers** — A standalone Playwright browser server (official Microsoft image). Hosts browser engines and exposes them via WebSocket on port 3000 (the controller does not embed browsers. It connects to the browser container over WebSocket, allowing independent version upgrades and scaling). *** ### 2. Prerequisites #### AWS Instance Requirements | Resource | Minimum | | -------- | ------------------------------------------------------------------------------------------------------------- | | OS | Ubuntu 22.04 LTS and later (officially supported by CB) or Amazon Linux 2023 (no official support by CB team) | | CPU | 4 vCPUs (x86 architecture) | | Memory | 8 GB RAM (16 GB recommended) | | Storage | 50 GB SSD (gp3) | > Actual hardware requirements depend on the number of required parallel tests. #### Network Access * Outbound: All outbound ports should be open. * Inbound: No inbound ports need to be opened. The controller initiates all connections outbound. *** ### 3. Setup #### 3.1 Install Docker > Please refer to the official Docker documentation. #### 3.2 Create Working Directory ```bash sudo mkdir -p /opt/cloudbeat && cd /opt/cloudbeat ``` #### 3.3 Create .env File Create a `.env` file with your CloudBeat configuration. Replace placeholder values with the credentials provided by CloudBeat: ```env PW_VERSION=1.57.0 CB_LOGGER_DEPLOYMENT_NAME=AWS_Docker_Playwright CB_CONTROLLER_API_KEY= CB_CONTROLLER_AGENT_ID= CB_CONTROLLER_LOCATION_KEY= CB_CONTROLLER_LOCATION_NAME= CB_CONTROLLER_GATEWAY_URL=https://api.cloudbeat.io:8080 CB_CONTROLLER_PARALLEL_TESTS=2 ``` #### 3.4 Environment Variables Reference | Variable | Description | | ------------------------------ | ---------------------------------------------------------- | | `PW_VERSION` | Playwright version for the browser container (e.g. 1.57.0) | | `CB_CONTROLLER_API_KEY` | API key for authenticating with the Gateway | | `CB_CONTROLLER_AGENT_ID` | Unique agent identifier assigned by CloudBeat | | `CB_CONTROLLER_LOCATION_KEY` | Location key for this runner instance | | `CB_CONTROLLER_LOCATION_NAME` | Human-readable name for this location | | `CB_CONTROLLER_GATEWAY_URL` | CloudBeat Gateway URL | | `CB_CONTROLLER_PARALLEL_TESTS` | Maximum number of parallel tests (default: 2) | #### 3.5 Create docker-compose.yml Place the provided `docker-compose.yml` file in `/opt/cloudbeat/`. The complete file is included in the Reference section below. *** ### 4. Deployment #### Start Services ```bash cd /opt/cloudbeat docker compose pull docker compose up -d ``` #### Verify ```bash docker compose ps ``` Both services should show status "Up" with playwright-browsers showing "healthy". ```bash docker compose logs cb.controller.playwright --tail 50 ``` Look for log entries confirming successful connection to the CloudBeat Gateway. #### Run a Test Trigger a test run from the CloudBeat web interface. Monitor in real time: ```bash docker compose logs -f cb.controller.playwright ``` *** ### 5. Upgrading Playwright Version 1. Update `PW_VERSION` in your `.env` file 2. Recreate the browser container: ```bash docker compose up -d playwright-browsers ``` > **Important:** The Playwright version in the browser container must match the version used in your test projects. ### 6. Upgrading the Controller ```bash docker compose pull cb.controller.playwright docker compose up -d cb.controller.playwright ``` > **Important:** It is recommended to update the controller periodically to benefit from the latest fixes and improvements. If a specific version is required due to a CloudBeat Gateway update, the CloudBeat team will notify you in advance *** ### 7. Docker Compose File ```yaml services: playwright-browsers: image: mcr.microsoft.com/playwright:v${PW_VERSION:-1.57.0}-noble container_name: playwright-browsers command: npx playwright@${PW_VERSION:-1.57.0} run-server --port 3000 --host 0.0.0.0 shm_size: '2gb' networks: - cb-network healthcheck: test: ["CMD", "node", "-e", "const http=require('http');http.get('http://localhost:3000',r=>{process.exit(r.statusCode===200?0:1)}).on('error',()=>process.exit(1))"] interval: 10s timeout: 5s retries: 3 start_period: 15s security_opt: - no-new-privileges:true cb.controller.playwright: image: cloudbeat/playwright-runner container_name: cb-controller-playwright volumes: - /etc/ssl/certs:/etc/ssl/certs:ro - /etc/ca-certificates:/etc/ca-certificates:ro environment: - DOTNET_NOLOGO=true - CB_LOGGING_LEVEL=info - CB_LOGGER_DEPLOYMENT_NAME=${CB_LOGGER_DEPLOYMENT_NAME} - CB_CONTROLLER_API_KEY=${CB_CONTROLLER_API_KEY} - CB_CONTROLLER_AGENT_ID=${CB_CONTROLLER_AGENT_ID} - CB_CONTROLLER_LOCATION_KEY=${CB_CONTROLLER_LOCATION_KEY} - CB_CONTROLLER_LOCATION_NAME=${CB_CONTROLLER_LOCATION_NAME} - CB_CONTROLLER_GATEWAY_URL=${CB_CONTROLLER_GATEWAY_URL} - CB_CONTROLLER_PARALLEL_TESTS=${CB_CONTROLLER_PARALLEL_TESTS} - PW_TEST_CONNECT_WS_ENDPOINT=ws://playwright-browsers:3000 networks: - cb-network security_opt: - no-new-privileges:true depends_on: playwright-browsers: condition: service_healthy networks: cb-network: external: false ``` # CloudBeat Playwright-Cucumber Agent - Docker Deployment Guide *** ### 1. Overview The deployment consists of two containers: * **cb.controller.cucumberjs**— The CloudBeat test controller and Playwright-Cucumber runner. Connects to the CloudBeat Gateway, executes tests, and reports results. * **playwright-browsers** — A standalone Playwright browser server (official Microsoft image). Hosts browser engines and exposes them via WebSocket on port 3000 (the controller does not embed browsers. It connects to the browser container over WebSocket, allowing independent version upgrades and scaling). *** ### 2. Prerequisites #### AWS Instance Requirements | Resource | Minimum | | -------- | ------------------------------------------------------------------------------------------------------------- | | OS | Ubuntu 22.04 LTS and later (officially supported by CB) or Amazon Linux 2023 (no official support by CB team) | | CPU | 4 vCPUs (x86 architecture) | | Memory | 8 GB RAM (16 GB recommended) | | Storage | 50 GB SSD (gp3) | > Actual hardware requirements depend on the number of required parallel tests. #### Network Access * Outbound: All outbound ports should be open. * Inbound: No inbound ports need to be opened. The controller initiates all connections outbound. *** ### 3. Setup #### 3.1 Install Docker > Please refer to the official Docker documentation. #### 3.2 Create Working Directory ```bash sudo mkdir -p /opt/cloudbeat && cd /opt/cloudbeat ``` #### 3.3 Create .env File Create a `.env` file with your CloudBeat configuration. Replace placeholder values with the credentials provided by CloudBeat: ```env PW_VERSION=1.57.0 CB_LOGGER_DEPLOYMENT_NAME=AWS_Docker_Playwright CB_CONTROLLER_API_KEY= CB_CONTROLLER_AGENT_ID= CB_CONTROLLER_LOCATION_KEY= CB_CONTROLLER_LOCATION_NAME= CB_CONTROLLER_GATEWAY_URL=https://api.cloudbeat.io:8080 CB_CONTROLLER_PARALLEL_TESTS=2 ``` #### 3.4 Environment Variables Reference | Variable | Description | | ------------------------------ | ---------------------------------------------------------- | | `PW_VERSION` | Playwright version for the browser container (e.g. 1.57.0) | | `CB_CONTROLLER_API_KEY` | API key for authenticating with the Gateway | | `CB_CONTROLLER_AGENT_ID` | Unique agent identifier assigned by CloudBeat | | `CB_CONTROLLER_LOCATION_KEY` | Location key for this runner instance | | `CB_CONTROLLER_LOCATION_NAME` | Human-readable name for this location | | `CB_CONTROLLER_GATEWAY_URL` | CloudBeat Gateway URL | | `CB_CONTROLLER_PARALLEL_TESTS` | Maximum number of parallel tests (default: 2) | #### 3.5 Create docker-compose.yml Place the provided `docker-compose.yml` file in `/opt/cloudbeat/`. The complete file is included in the Reference section below. *** ### 4. Deployment #### Start Services ```bash cd /opt/cloudbeat docker compose pull docker compose up -d ``` #### Verify ```bash docker compose ps ``` Both services should show status "Up" with playwright-browsers showing "healthy". ```bash docker compose logs cb.controller.cucumberjs --tail 50 ``` Look for log entries confirming successful connection to the CloudBeat Gateway. #### Run a Test Trigger a test run from the CloudBeat web interface. Monitor in real time: ```bash docker compose logs -f cb.controller.cucumberjs ``` *** ### 5. Upgrading Playwright Version 1. Update `PW_VERSION` in your `.env` file 2. Recreate the browser container: ```bash docker compose up -d playwright-browsers ``` > **Important:** The Playwright version in the browser container must match the version used in your test projects. ### 6. Upgrading the Controller ```bash docker compose pull cb.controller.cucumberjs docker compose up -d cb.controller.cucumberjs ``` > **Important:** It is recommended to update the controller periodically to benefit from the latest fixes and improvements. If a specific version is required due to a CloudBeat Gateway update, the CloudBeat team will notify you in advance *** ### 7. Docker Compose File ```yaml services: playwright-browsers: image: mcr.microsoft.com/playwright:v${PW_VERSION:-1.57.0}-noble container_name: playwright-browsers command: npx playwright@${PW_VERSION:-1.57.0} run-server --port 3000 --host 0.0.0.0 shm_size: '2gb' networks: - cb-network healthcheck: test: ["CMD", "node", "-e", "const http=require('http');http.get('http://localhost:3000',r=>{process.exit(r.statusCode===200?0:1)}).on('error',()=>process.exit(1))"] interval: 10s timeout: 5s retries: 3 start_period: 15s security_opt: - no-new-privileges:true cb.controller.cucumberjs: image: cloudbeat/cucumberjs-runner container_name: cb-controller-cucumberjs volumes: - /etc/ssl/certs:/etc/ssl/certs:ro - /etc/ca-certificates:/etc/ca-certificates:ro environment: - DOTNET_NOLOGO=true - CB_LOGGING_LEVEL=info - CB_LOGGER_DEPLOYMENT_NAME=${CB_LOGGER_DEPLOYMENT_NAME} - CB_CONTROLLER_API_KEY=${CB_CONTROLLER_API_KEY} - CB_CONTROLLER_AGENT_ID=${CB_CONTROLLER_AGENT_ID} - CB_CONTROLLER_LOCATION_KEY=${CB_CONTROLLER_LOCATION_KEY} - CB_CONTROLLER_LOCATION_NAME=${CB_CONTROLLER_LOCATION_NAME} - CB_CONTROLLER_GATEWAY_URL=${CB_CONTROLLER_GATEWAY_URL} - CB_CONTROLLER_PARALLEL_TESTS=${CB_CONTROLLER_PARALLEL_TESTS} - PW_TEST_CONNECT_WS_ENDPOINT=ws://playwright-browsers:3000 networks: - cb-network security_opt: - no-new-privileges:true depends_on: playwright-browsers: condition: service_healthy networks: cb-network: external: false ```