Create and configure pipelines

ALM Octane lets you look at your CI server jobs and steps graphically instead of as lists of information. This flow of jobs and steps is called a pipeline.

To learn more about pipelines in ALM Octane before creating them, see Pipelines: Integrate with your CI server.

Note: If you are working with Jenkins: You can similarly create and configure pipelines using the HPE ALM Octane CI plugin on the Jenkins CI server. For details, see Create and configure pipelines in the Jenkins UI.

Add a pipeline in ALM Octane

  1. Prerequisites

    DevOps admin permissions are required.

  2. In ALM Octane, go to the Pipelines module and open the Pipelines tab.

  3. Click + to add a pipeline.

  4. Select a CI server. The list displays the servers created on the CI Servers settings page of the current workspace.

  5. Select the root job from which you want ALM Octane to start the pipeline. The list displays the jobs defined on the CI server you selected. If the communication with the server fails, the list will not be available.

  6. Enter a name for the pipeline and, optionally, assign the pipeline to a release.

  7. Select Notify committers upon build failure if you want ALM Octane to send an email to people whose commits were included in a build that failed.

    You can edit this option later in the pipeline's Details tab. DevOps admin permissions are required.

    For more details, see Track commits associated with a pipeline run.

ALM Octane retrieves the CI server pipeline and displays it graphically. The pipeline is initially built based on the structure ALM Octane discovers on the CI server. When the pipeline runs on the CI server, ALM Octane adds any additional steps it discovers running in the pipeline.

Jenkins example

Above the toolbar, you can edit the pipeline's name and its release. You can also see the build number and when it last ran.

Back to top

Explore the pipeline

After a pipeline is created, you can graphically see the job steps, their status, and their flow, starting from the root job of the pipeline.

Here are visual clues for understanding and working with the display as you explore the pipeline in the Topology tab. After the pipeline runs, you can see a comprehensive overview of the run results in the Overview tab. For details, see View pipeline run results.

Visual clue Description

The pipeline's ID and name, and the build number of the last run.

  • Click the pipeline's ID to open the pipeline and learn more about its runs and quality.

  • Click the build number to view details about the last run.

Summary data about the pipeline's last run. Click the build number to open the specific run on the CI server.

If you have SCM integration set up via your CI server, you can see information about commits associated with the pipeline run. See, Supported SCM systems.


Configuration view. When the configuration view is off, the pipeline steps' status is displayed.

This switch affects the type of data displayed on the pipeline steps:

Status. Each step displays its build number, duration, and status (success, failure, warning) of the last time it ran. For steps that run tests, the status of the last test run is displayed.

Configuration. Each step displays only the tags that you defined in its configuration.

Click to view the pipeline in a Flat view or Tree view.

Tree view. Displays the hierarchy and flow of the pipeline.

Flat view. Displays the pipeline steps side by side without describing the hierarchy or flow. This view is useful for gaining an overview of complex pipelines.

In this view, you can also filter pipeline steps. For details, see Filter pipeline steps (Topology tab).

A step in the pipeline.

If the step is gray, this means it did not run in the last run of the pipeline. The more times the pipeline runs without running this step, the less vividly the step appears in the pipeline.

  • Click the step's name to open the job on the CI server.

  • Click the build number to open the specific run on the CI server.

A pipeline step that ran automated tests.

Click the test statuses to open the tests in the Quality module.

For a pipeline that displays hierarchy, click to expand and collapse the steps that run as part of their parent step. (inner jobs)

Steps on the same side of a dotted line run in parallel to each other. (parallel jobs)

Steps on the right side of a dotted line run after the steps on its left side end. (sequential jobs)

Steps that run as part of the pipeline.

In a pipeline that displays hierarchy, the steps after this arrow run only after the calling step and its children end. (sequential jobs)

Click to label the step type as a compile, package, deploy, or test.

Click to configure step information, which is added to the pipeline step as a tag. You can use tags later, for example, for filtering test run results.

You can specify:

  • Test-related information: Framework, test type, testing tool, and test level.

  • The environment on which the step runs (browser, operating system, database, and so on). You can also define conditional environment tags that are set according to build parameter values when the step runs.

For details, see Configure steps: Define test and test run information.

Back to top

Label and configure pipeline steps (Topology tab)

Enhance the pipeline's usefulness in ALM Octane by labeling and configuring. This makes it easier to understand the purpose of the steps and provides additional contextual information for test run results.

DevOps admin permissions are required.

Label steps according to job type

Click the label at the top right of a step, and select a job type for the step. The label helps you understand the pipeline flow. In the flat pipeline view, you can also filter the pipeline to show only steps with specific labels.

Job types include: Compile, Package, Deploy, and Test.

Configure steps: Define test and test run information

For pipeline steps that run tests, add environment and testing information about the step.

This adds tags to your pipeline step. When this pipeline step runs tests, its tags are added to the tests and test runs. You can then filter test run results in ALM Octane according to these tags, and enhance your product and release quality analysis.

  1. Click the Configuration button on the bottom right of the step.

    If a step runs tests that you do not want to track in ALM Octane, select Ignore test run results, and skip the rest of the steps below. When this step runs tests, the results are not sent to ALM Octane, and it does not create the corresponding tests.

    For example, we recommend that you use this option to ignore unit tests. This will prevent unnecessary load on your ALM Octane, which could result in performance issues.

    You can also specify whether to delete test run results that were previously collected from this step. If all of a test's run results are subsequently deleted, the automated test is deleted as well.

    Caution: Deleting test results will affect your pipeline's build run history. In addition, failure analysis will not be available for steps whose test results are ignored.

  2. In the Test fields tab, add information about the type of tests the step runs, and the tools and framework it uses to run them.

    Select from the predefined values:

    • Framework: One of the values in the list. For example: JUnit, TestNG, UFT.

    • Test type: One of: Acceptance, End to End, Regression, Sanity, Security, and Performance.

    • Testing tool: One of the values in the list. For example: Manual Runner, Selenium, UFT, LeanFT, StormRunner, LoadRunner.

    • Test level: One of: Integration Test, System Test, Unit Test.

    You can add values to the Framework and Testing tool lists. To do this, add tags to the pipeline step using the API, or the Jenkins UI.

    Note: ALM Octane automatically sets the Testing tool field for UFT, LoadRunner, and StormRunner Load tests discovered on Jenkins pipelines. For UFT tests, the Framework is set as well.

    If you manually added tags to the pipeline step that runs these test, your tags override the automatic ones.

  3. In the Testing Environment tab, add information about the environment on which the step runs. For example, the operating system, browser, and database.

    Environment tags are grouped by category. ALM Octane provides several environment tags out-of-the-box. You can also define your own tags, according to your project developing model.

    Do one of the following:

    Use an existing environment tag

    Click the Environment box and select existing tags.

    Tip: Type in the box to search for a specific value.

    Add a custom environment tag
    1. Click the Environment box, and click Add New.

    2. Select a Category for your new tag.

      Tip: Type in the box to search for a specific value or to provide a new one.

    3. Enter the name for your new Tag.


    • Add a Lab Machine category with tags for each machine you use for nightly runs.

    • Add tags for specific browser versions or development branches.

    Create conditions for setting environment tags during the build run, based on build parameter values

    In the table, add a row for each environment tag that you want to assign dynamically.

    In each row, specify:

    Parameter name + value ==> Tag

    Select the build parameter name from the list of build parameters available for this step.

    If you use the Multijob plugin on Jenkins, the pipeline displays child steps, generated during the build run. Each one represents a set of build parameter values.

    Configure conditional environment tags on the parent step. These are used to tag the generated child steps. You cannot modify a child's configuration.

Example: This Jenkins step, QA-Functional-Chrome, is labeled as a Test and has the following tags configured:

  • Test fields: Framework = TestNG, Test type = End to End, Test level = Integration Testing, Testing tool: Selenium.

  • Testing Environment: WinServer2012 (OS), MSSQL (DB), QA (AUT Env), Chrome (Browser).

Back to top

Filter pipeline steps (Topology tab)

Filter a pipeline by label or job name, to display only pipeline steps with a certain label and/or steps with a specific string in their name.

If you set up a filter on a specific pipeline, that filter is used again the next time you view the pipeline.

In the pipeline flat view:

  • Filter by label. Select from the labels on the right to specify the type of pipeline steps you want to see.
  • Filter by job name. Type in the context search box to see only steps whose name contains the specified string.

If you filter by label and by job name, the pipeline displays only steps that match both filters.

Back to top

Select which pipelines to display

If you have a large number of pipelines defined, you can filter the list of pipelines to display only the ones you want to work with.

In the toolbar above the list of pipelines, click the down arrow on the Select pipelines button and select the pipelines you want to display.

Your selection is retained for future sessions as well.

Delete a pipeline

DevOps admin permissions are required.

Click the X on the pipeline box in the list of pipelines on the left.

If you delete a pipeline: 

  • All of the pipeline's labels and configuration information are lost.

  • The run results of automated tests run by this pipeline are no longer updated.

Back to top

Next steps: