Bitbucket Pipeline Builds Test

Bitbucket Pipeline is an integrated continuous integration (CI) / continuous delivery (CD) service, built into Bitbucket. One or more Bitbucket Pipelines can be configured to automatically build, test and even deploy your code through different branches without affecting the main Bitbucket repository. The Pipelines execute the operations based on a configuration file committed to the main Bitbucket repository. The Pipelines give you end-to-end visibility from coding to deployment and bring the status of builds on the branches into your repository. In the process, you can also view the status of different branches and commits everywhere in Bitbucket, thus giving you crucial visibility on the status of your builds when you branch and before you merge.

With Bitbucket Pipelines, all teams can determine any failures during code building/testing/deploying operations, fix them as earlier as possible and deliver better software faster. If, for any reason, build operations using the Pipelines on fail or are halted or stopped abruptly, then the code will not be built as expected. This in turn will delay tasks that should be performed after the build operation and code synchronization and reduce reliability. As a result, the continuous delivery of software will become questionable. To avoid such anomalies, administrators can use the Bitbucket Pipeline Builds test to proactively detect the status of builds executed on branches through Pipelines.

This test continuously monitors the branches of the repositories, and for each branch of each repository, proactively reveals the number of successful builds and the number of builds that failed/stopped/halted and are in pending state. These statistics help administrators to find out how well/badly the build operations are performed on each branch, proactively detect the issues, if any, and take remedial actions immediately.

Target of the test : Bitbucket

Agent deploying the test : A remote agent

Outputs of the test : One set of results for each repository:branch combination in the Bitbucket account.

Configurable parameters for the test
Parameters Description

Test period

This indicates how often should the test be executed.

Host

The host for which this test is to be configured.

Port

The port at which the host listens to.

Username, Password and Confirm Password

Specify the user name and password assigned to the Bitbucket account to be monitored in the Username and Password text boxes.

Then, confirm the password by retyping it in the Confirm Password text box.

Excluded Repositories

Here, you can provide a comma-separated list of repository names that you do not want to monitor. For instance, to exclude repositories with names that contain 'ver1' and 'ver2' from monitoring, your specification should be: *ver1*,*ver2*

DD Frequency

Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD frequency.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Total builds

Indicates the total number of builds that run on this branch.

Number

 

Success builds

Indicates the number of builds that run successfully for this branch.

Number

The detailed diagnosis of this measure reveals the name of author, commit ID, brief message, trigger type, build ID, the time at which the build operation was started and the total time duration taken for build operation in seconds.

Failed builds

Indicates the number of builds that failed on this branch.

Number

The detailed diagnosis of this measure reveals the name of author, commit ID, brief message, trigger type, build ID, the time at which the build operation was started and the total time duration taken for build operation in seconds.

Pending builds

Indicates the number of builds that are pending on this branch.

Number

The detailed diagnosis of this measure reveals the name of author, commit ID, brief message, trigger type, build ID, the time at which the build operation was started and the total time duration taken for build operation in seconds.

Halted builds

Indicates the number of builds that are halted on this branch.

Number

The detailed diagnosis of this measure reveals the name of author, commit ID, brief message, trigger type, build ID, the time at which the build operation was started and the total time duration taken for build operation in seconds.

Stopped builds

Indicates the number of builds stopped on this branch.

Number

The detailed diagnosis of this measure reveals the name of author, commit ID, brief message, trigger type, build ID, the time at which the build operation was started and the total time duration taken for build operation in seconds.