Run pipelines

After you create pipelines, you can run them on your CI server. You can then view and analyze the pipeline run results, and begin tracking your build quality.

In this topic:

What happens when a pipeline runs

When a pipeline runs, the following occurs.

Action	Details
The results of the pipeline step runs are collected.	The builds that comprise the run are collected. 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.
The results of the automated tests that run as part of the pipeline are collected.	Automated test and test run entities associated with the test run results are created. If a relevant automated test already exists, the results are associated with that test. For details, see Create automated tests. You can view the automated tests alongside the manual tests. View the test run results when tracking the quality of your products and releases.
SCM commit information is collected.	Any available SCM commit information is collected.
The pipeline run vulnerabilities are displayed.	If you set up security testing integration, a pipeline run triggers a security assessment of your application's code, and the newly found vulnerabilities in the pipeline run are displayed. This enables you to quickly identify and correct security vulnerabilities introduced into the code. For details, see Security and code coverage.
JaCoCo and LCOV reports from Jenkins are received.	If you set up code coverage tracking, your JaCoCo and LCOV reports are received from Jenkins. For details, see Track code coverage in pipeline runs.
The pipeline run details are displayed.	After the pipeline run ends, detailed information is displayed about the pipeline status, the status of the pipeline's builds and test runs, commits that may be related to failed test runs, and code coverage information. This information helps you analyze the quality and status of your build, product, release, and milestones.

Back to top

Trigger a pipeline run (optional)

You can trigger a pipeline run directly from within OpenText Core Software Delivery Platform.

To trigger a pipeline run:

1. In the Pipelines module, open the Analysis tab and select a pipeline in the summary bar.

2. From the pipeline's menu options, select Run. The CI server is triggered to run the pipeline's root job.

3. If your CI server job is parameterized, a dialog opens to enable you to select parameter sets and parameter values to use in the 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.

   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.

   • For Azure DevOps, pipeline parameters must be variables defined in the pipeline metadata. Variables defined in other ways, such as in the .yml file, or native Azure DevOps parameters are not supported.

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

Back to top

Abort a pipeline run in Jenkins

You can stop a pipeline run, when using the Jenkins plugin version 7.0 and later.

To abort a pipeline run:

1. In the Pipelines module, open the Analysis tab and select a pipeline in the summary bar.

2. Drill down in the pipeline to the list of pipeline runs.

3. Select a run, and click Abort in the toolbar.

Back to top

Run Azure DevOps pipelines

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

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

To run an Azure DevOps pipeline (as a user):

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, it is shown in the Pipeline module and you can run it like any other entry.

   If you tried to run an Azure DevOps pipeline and you received a message indicating that you need to upgrade the version of the extension, you must rerun the pipeline from Azure DevOps after the upgrade.

2. To run the pipeline 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 OpenText Core SDP Azure DevOps extension version 0.2.7.0 or higher.
3. To add the variables that you defined in Azure, you must manually synchronize with Azure, since the processing is asynchronous. In OpenText Core SDP, 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 an Azure DevOps pipeline for a run, the Run Pipeline Parameters dialog box opens. In this dialog box, you can specify the Azure DevOps branch upon which to run the pipeline. If the branch is not valid, an error message will be issued. To run the same pipeline on different branches, rerun the pipeline and specify the relevant branch name.

Back to top

Known issues for pipeline runs

The following are some known issues in pipeline runs.

Issue	Description
Commit limit	There is a limit to the number of commits allowed between each build. The number of allowed commits depends on the repository type. For example, in Git type Azure repositories you can make 1000 commits, in GitHub you can make 200 commits, but in the GitHub Enterprise server you can only do one commit between builds.
Build duration in Azure:	The build duration shown for the pipeline run may deviate slightly from the actual duration shown in Azure. The longer the run, the smaller the deviation.
Multiple repositories in GitHub	In GitHub pipeline runs, commits to multiple repositories are not supported within a single job. You must create a separate job for each repository.

Back to top

Next steps:

• Pipeline status and trend - Overview tab
• Analyze build failures
• Analyze test failures