Auto actions

You can add automatic actions to your release process that trigger common tasks, such as CI run jobs, email notifications, and the generation of document reports.

Prerequisites

Ensure that the prerequisites below are met for the following auto action types:

Run job: Ensure that the necessary integrations are configured for your workspace. For details, see Integrations overview.
Update entities and Add comment: Ensure that an API key for auto actions is defined in the Details tab of the release process. For details, see API keys.
Generate document report:
- Ensure that an API key for auto actions is defined, and that the API key has the Generate Document Report permission from the General System Actions category. If necessary, contact your admin to grant this permission to the API key user. For details, see API keys.
- Make sure that you have defined at least one document report template. For details, see Document reports.

API keys

Within your release processes, some auto actions that interact with ALM Octane require an API key. This includes auto actions such as Update entities, Add comment, and Generate document report.

You specify the API key for each release process, in the API key for auto actions field.

The auto actions associated with this key are recorded in the item's history as actions performed by the API key. For example, for an Update entities auto action, the updates are recorded in the item's history as an action performed by the API key for auto actions user.

Users with the Workspace Admin or Release Manager roles can define API keys. Make sure that the role defined with the API key has the necessary privileges to automate the actions that users need to perform. For example, you could create an API key with a custom role to add comments to certain entities and use it specifically to automate the process of adding comments to these entities as part of the release workflow. For details on creating the API keys, see API access.

Note: This section does not apply to the API key for the Generic Service REST Call auto action, which uses authentication headers.

Common auto actions

The following are some common auto actions:

Type

Details

Add comment

Adds comments to the selected item types. This capability is available for:

Work items, such as features and backlog items.
Quality items, such as tests and test runs.

Tip: To narrow down the list of items to which a comment will be added, apply a filter. For example:

To only add comments to items associated with the release defined for the current release process, select Linked Processes > Releases. In the popup, select Release Process.Releases and click OK.
To send a notification when a process reaches a specific step, select This Release Process as the entity type. Users will receive these notifications when they follow this release process.
To only add comments to items that are associated with the milestone defined for the current release process, select Linked Processes > Milestones. In the popup, select Release Process.Milestones and click OK.

Note: Comments are added on behalf of the API key. Ensure the defined API key user has permissions to add comments to the selected item type.

Generate document report

Generates a document report based on the selected template.

The template drop down only includes templates that are shared with all users.

If the auto action is successful, the owner of the auto action is notified of the report generation in the My Work area.

Note the following:

The report is generated on behalf of the API key for auto actions.
Document report templates that include widgets are not supported.
The report is not available for users with data access control enabled. For details, see Data access control.
If the auto action is deleted, the generated report is no longer available.

Admins can configure email templates to include a link to the auto-action-generated document report. For details, see Email templates.
You can also use variables to include a document report or a link to the report , in emails and notifications. For details, see Create process variables.

Send email

Sends an email with a specific message. Specify the To, CC, and BCC fields, the subject, content, and importance level.

Update entities

Performs an update to Work items, such as features and backlog items.

If the auto action succeeds, the new values replace the original ones, for the specified type.

Specify the following values:

Entity type: The type of items that the auto action should update.

Tip: To set fields in the current release process, select This Release Process as the entity type. A common use case would be to define a dynamic variable and then use it to set the release version number field. This field would be visible to all users when viewing the release process grid.
Fields to update: The item fields that the auto action should update. You can also add tags and define values for the fields that you specify.

Filter: Define filters to narrow down the list of items to update. For details, see Filters. The following table shows several examples:

Desired action	Steps
Update items associated with the release defined for the current release process	Select Linked Processes > Releases. In the popup, select Release Process.Releases and click OK.
Update items associated with the milestone defined for the current release process	Select Linked Processes > Milestones. In the popup, select Release Process.Milestones and click OK.

Note: By default, the maximum number of items that can be updated by an auto action is set to 500. Your admin can change this number by modifying the RC_AA_UPDATE_ENTITIES_MAX_SIZE parameter. For details, see Configuration parameters.

After you choose an action, you provide its field values. For details, see Define actions.

CI server auto actions

Release processes let you perform automated actions on CI servers. This section describes how to create Run job auto actions for common CI servers.

For a CI action, you define the following:

Field	Details
CI server	The CI server whose job the auto action should run. The supported servers are: Jenkins, Bamboo, Azure DevOps, PulseUno, GitLab, and TeamCity. Note: Jenkins: You must upgrade your Jenkins plugin to version 7.4 or later. GitLab: You must upgrade your GitLab service to version 1.1.128 or later. TeamCity: You must upgrade your TeamCity plugin to version 1.4.4 or later.
CI job	A job that the auto action should execute, depending on the selected CI server.
Execution parameters	Job execution parameters that should be passed to the CI server. Note: The parameters are defined with the default values, or the latest values set on the CI server. To change a value, clear the default value and enter a new one. You can define variables and use them as parameters. For details, see Auto actions. The newly defined values are fixed for a job that the given auto action should run. They are not affected when values on the respective CI server change. If the execution parameters are not defined in the auto action details, the CI job runs with the default parameters set on the CI server. You can check the parameter details in the execution message. For multi-branch Jenkins jobs, parameters are provided for branches defined as default on the CI server. To use parameters for a specific branch, list this branch as default on the CI server.
Branch name	The branch on which the job should run. Note: PulseUno jobs: If the PulseUno parameters, such as a branch name and a changeset ID, are not defined, the auto action triggers a job on the latest changeset ID and the default branch. GitLab jobs: If the branch name is not defined, the auto action runs a job on the default branch. You can also use the Branch name field to define CI tags. Unlike with branches, where jobs run on the latest version of code, tags help you run jobs on specific versions, regardless of the commit time. If a GitLab branch and tag have the same name, auto action fails. Jenkins jobs: You must define a branch name for a Jenkins job. If the branch name is not defined, the auto action fails. If the branch name is not defined, the auto action runs a job on the default branch. For multi-branch Jenkins jobs, if a branch name is not defined in ALM Octane, and default branches are not set on the CI server, the auto action fails.

CD server auto actions

Release processes let you perform automated actions in on CD servers.

Technical preview: The Deployment Automation integration is provided as a technical preview. It may require a separate license in the future.

Type	Details
Run application process	Deployment Automation: Auto actions can run application processes using snapshots or component versions. Specify the CD server, the application and its environment, a process, a snapshot/component and their versions. Tip: You can parameterize the Deployment Automation component version and snapshot, to run the application process for multiple component versions and snapshots. For example, you can run the auto action with Expression mode on, and again with it off, by using different input variables for the snapshot. For details, see Auto actions. Note: Auto actions for Deployment Automation (DA) processes do not support the cancellation of application approvals within DA.

Type

Details

Run application process

Deployment Automation: Auto actions can run application processes using snapshots or component versions.

Specify the CD server, the application and its environment, a process, a snapshot/component and their versions.

Tip: You can parameterize the Deployment Automation component version and snapshot, to run the application process for multiple component versions and snapshots. For example, you can run the auto action with Expression mode on, and again with it off, by using different input variables for the snapshot. For details, see Auto actions.

Note: Auto actions for Deployment Automation (DA) processes do not support the cancellation of application approvals within DA.

REST auto actions

You can trigger a REST Call or Poll auto action as part of your release process flow.

There are several configuration parameters that can be customized for your needs. These parameters begin with the RC_AA_REST prefix. For example, admins can set a timeout value for REST requests using the RC_AA_REST_CALL_REQUEST_TIMEOUT parameter (by default 60 seconds) or RC_AA_REST_CALL_ALLOWED_URL_LIST to specify the allowed URLs. For details, see Configuration parameters.

REST Call actions

A REST Call action lets you integrate with a variety of systems and services, extending the functionality of the release process and improving its efficiency. Using REST calls, you can automate and streamline your workflow by adding REST API calls directly from within your applications.

Most request fields allow you to use parameterization. Click {x} in the field to open a list of the available variables and fields. For details, see Release process variables.

To create a REST Call auto action:

Select Generic Service > REST Call as the action type.
Select an HTTP method: DELETE, GET, POST, or PUT.
Optionally expand the Auth type field to use an API key with the REST call.
Specify a URL.
Add Body content. Use a JSONPath query language expression to extract relevant data from the response. You can then use the results to set variable values in post processing.
Optionally, click + Add Header to add a header to the API call.
Optionally, create a named expression to parse the response.
Optionally, implement advanced output processing. For details, see Advanced output processing.

REST Poll actions

Available in versions: 24.1 and later

A poll action allows you to check the status of an earlier asynchronous REST call.

You can use poll actions to check the status of a prior REST Call operation, for example an action that you expect to take a long time to complete. You specify success and/or failure conditions for the step that needs to be completed before continuing. You can also use a poll action to wait for a process to finish before processing a quality gate.

Admins can set the following properties, whose thresholds indicate a failed step:

Number of polling attempts, by default 30.
Interval between the polling attempts, by default a maximum interval of 1440 minutes and a minimum of 1 minute. The interval is also used for all subsequent polling requests—not just the initial request.
Request timeout.
REST poll allowed list.

For details, see Configuration parameters and refer to the parameters beginning with RC_AA_REST_POLL.

Note: When evaluating the conditions of the poll action, preference is given to the success conditions. For example, if the poll call returns a Success status based on the polling condition, the step will be marked as success, even if the failure condition was also met.