Run pipelines

First you create pipelines as described in Create and configure pipelines. You then run the pipelines on your CI server. You can then view and analyze the pipeline run results, and begin tracking your build quality.

What happens when a pipeline runs

When a pipeline runs, the following occurs:

Action Details
ALM Octane collects the results of the pipeline step runs.

ALM Octane collects the builds that comprise the run.

The pipeline run's number is the build number of the root step in the pipeline.

The pipeline run's status is determined by the result of the root job. Therefore, for the pipeline run status to reflect the results of other jobs in the flow, make sure that on your CI server, the results of those jobs are aggregated up to the root job.
ALM Octane collects the results of the automated tests that run as part of the pipeline.

ALM Octane creates automated test and test run entities associated with the test run results it collects. If a relevant automated test already exists, the results are associated with that test. For more details, see Create automated tests.

View the automated tests alongside the manual tests in ALM Octane. View the test run results when tracking the quality of your products and releases.
ALM Octane collects SCM commit information. ALM Octane collects any available SCM commit information.
ALM Octane displays the pipeline run vulnerabilities.

If you set up security testing integration, a pipeline run triggers a security assessment of your application's code, and ALM Octane displays the newly found vulnerabilities in the pipeline run.

This enables you to quickly identify and correct security vulnerabilities introduced into the code. For details, see Security and code coverage integrations.
ALM Octane receives your JaCoCo and LCOV reports from Jenkins.

If you set up code coverage tracking, your JaCoCo and LCOV reports are sent from Jenkins to ALM Octane. For details, see Track code coverage in pipeline runs.
ALM Octane displays the pipeline run details.

After the pipeline run ends, ALM Octane displays detailed information about the pipeline status, the status of the pipeline's builds and test runs, commits that may be related to failed test runs, code coverage information, and more.

This information helps you analyze the quality and status of your build, product, release, and milestones (when relevant).

Back to top

Trigger a pipeline run from ALM Octane (Optional)

You can trigger a pipeline run directly from ValueEdge and ALM Octane:

  1. In the ALM Octane Pipelines module, open the Pipelines tab and select a pipeline in the upper pane.

  2. From the pipeline's menu options, select Run.

    ALM Octane triggers the CI server to run the pipeline's root job.

  3. If your CI server job is parameterized, a dialog will open to enable you to select parameter sets and parameter values to use in this pipeline run.

    You can select a parameter set to use a set of predefined values. If you leave the parameter set empty you can use the default parameter values, or (depending on your permissions) enter other values that you want to use in this run. For details, see Use parameter sets when creating a pipeline. After a pipeline runs, you can see which parameters and parameter values were used in the pipeline run's Details tab.

      Note:

    • Changing parameter values requires the Override Parameters on Run permission.

    • In GitLab, the Details tab shows only those parameters whose values are different than the default values.

    • Pipeline parameters for Azure DevOps must be variables defined in the pipeline meta data. Variables defined in other ways, such as in the .yml file, and native Azure DevOps parameters are not supported.

On all CI servers besides TeamCity, the pipeline steps run under the CI Server user, or the Azure (TFS) PAT that you specified when configuring the ALM Octane CI plugin on the CI server. The pipeline run is limited by the permissions assigned to this user.

Back to top

Run Azure DevOps pipelines

To run Azure DevOps pipelines, admins and users must prepare the ALM Octane environment.

For admin guidelines, see Admin setup for Azure DevOps pipelines.

As a user, follow these steps to run an Azure DevOps pipeline:

  1. Run the pipeline at least once from the Azure DevOps side. Azure DevOps pipelines cannot be created through the standard Create New Pipeline command. The pipeline will not appear in the drop down list of pipelines (Pipeline > Create New Pipeline).

    After you run the pipeline one time from the Azure DevOps side, ALM Octane will display it in the Pipeline module and you can run it like any other entry.

    If you tried to run an Azure DevOps pipeline and ALM Octane indicated that you needed to upgrade the version of the extension, you must rerun the pipeline from Azure DevOps again after the upgrade.

  2. To run the ALM Octane with parameters, define them in Azure DevOps within the pipeline meta data. Parameters defined in the .yml file or native Azure DevOps parameters are not supported. This functionality requires the ALM Octane Azure DevOps extension version 0.2.7.0 or higher.
  3. To add the variables that you defined in Azure to the ALM Octane, you must manually synchronize with Azure, since the processing is asynchronous. In ALM Octane, click Sync with CI. Wait for the status message to indicate that the synchronization is complete, and then refresh the pipeline view.
  4. Select a branch. When you select to run an Azure DevOps pipeline, ALM Octane opens the Run Pipeline Parameters dialog box. In this dialog box, you can specify the Azure DevOps branch upon which to run the pipeline. If the branch is not valid, ALM Octane will issue an error message. To run the same pipeline on different branches, rerun the pipeline and specify the relevant branch name.

Note: Unlike other CI integrations, Azure DevOps pipeline runs are processed asynchronously. Therefore, when you initiate a pipeline run, ALM Octane issues a message that your request is being processed. After the processing, ALM Octane issues another message indicating if the pipeline run succeeded or failed, with a reason for the failure.

Known Issues

The following known issues apply to the ALM Octane Azure DevOps integration:

Commit limit: A known integration issue is a limit of the number of commits allowed between each build. The number of allowed commits depends on the Azure repository type. For example, for Azure Repos Git you can make 1000 commits, for GitHub you can make 200 commits, but for GitHub Enterprise server you can only do one commit between builds.

Build duration: The build duration shown in ALM Octane for the pipeline run may deviate slightly from the actual duration shown in Azure. The longer the run, the smaller the deviation.

Back to top

Next steps: