The Bitbar API service provides plenty of requests that help to not only query the test results but also configure test settings and directly launch test runs in Bitbar Device Cloud from your environment. With the cloud domain change two months ago, it’s good time to recap what API calls are needed and how to get the most out of the Bitbar API service to improve DevOps pipeline efficiency and developer productivity.

More specifically, the reasons to use the API service are simple.

You already have an optimal CI/CD pipeline but want to expand test coverage with additional devices.

Your current testing capacity is not sufficient and you want to use additional devices from the cloud.

Or you are just frustrated to traverse multiple UIs to relaunch your tests against new app versions.

The below steps describe how to get information about existing settings and projects from Bitbar Cloud and how to launch test runs in the cloud with changing apps or tests.

In all of the examples below, you’ll need to replace `${CLOUD_URL}` with your cloud URL ${API_KEY}. For public cloud users that would be ‘https://cloud.bitbar.com/‘ while Bitbar Enterprise customers with Private Cloud or On-Premise setup will have different addresses. Most of the used resources are behind authentication, for which we use the API key variable ${API_KEY}. Set this to your own.

Also we’ll use curl to demonstrate the calls, but of course you can use any other scripting/programmatic approach that better suits your needs.

Gathering Project and Run Information

If you already have some projects, then it’s a natural first step to check the configurations of these projects. You’ll need this information when you want to start new runs on existing projects.

Getting project information

To query all of your projects, you need to use the ‘/api/v2/me/projects‘ endpoint. This will return all of your projects and specifically the project IDs that is needed to programmatically interact with the project. This also applies to when you create new test runs.

To automate the launching of the last run, you can just get the latest run from a project and then restart it. If you don’t know the project ID, you’ll need to find it using the above calls and filtering options.

Getting available frameworks

In the previous example we have been working on existing projects. To create a new project you’ll need to know the testing framework that your tests are going to use. There are multiple frameworks available and not all are available to all users. Query to check which you can use:

The response message will have the framework names (e.g. Appium Android Server Side), the required files and types etc. You’ll mostly need the framework name while creating a new project or the ID when launching a new test run for an existing project.

Creating a new project

If you are starting from scratch, you’ll need to create a new project before you can start test runs. Creating a project is also a simple API call away, but you need to know some parameters for the project to behave as you expect. These are the project name and framework type (available types queried earlier). Here’s an example of such a call.

Launching Runs

Once you have uploaded files and stored the response IDs, you can start a new test run with all the configurations for the project you want. This is the best approach to make sure which configuration gets used with your run.

The run configuration of the test run should be provided as part of the run command like above with ‘--data‘ parameter.

In earlier API versions, it was possible to start a test run in two phases. In some heavily automated environments, this could cause a case where a second configuration was uploaded before the first run had yet started. This of course caused confusion when reviewing results!

Getting Familiar With Bitbar API

Private Cloud users and all registered users (after release 2.61, planned for 28.6.) can access the API documentation at $CLOUD_URL/cloud/swagger-ui.html. This Swagger service allows you to read through the API documentation and even try running commands from the web interface. This way you can try out your calls before writing your scripts for CI automation!