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.
  • 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.

Back to top

API keys

Within your release processes, some auto actions require an API key. This includes auto actions such as Update entities, Add comment, and Generate document report. For details on creating the API keys, see API access.

You specify the API key for the 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 can 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.

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

Back to top

Common auto actions

The following are some common auto actions.

Adds comments to the selected item types. The supported item types are:

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

To restrict the set 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, click the cross-filter button , and select Releases. For the value, select Release Process.Releases and click OK.
  • To only add comments to items associated with the milestone defined for the current release process, select Linked Processes, click the cross-filter button , and select Milestones. For the value, select Release Process.Milestones 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.

Generates a document report based on the selected template. The available templates only include 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.

Tip:  

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

Note the following limitations:

  • 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.

Sends an email with a specific message.

Specify the To, CC, and BCC fields, the subject, content, and importance level.

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.

Back to top

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 runs.

The supported servers are: Jenkins, Bamboo, Azure DevOps, PulseUno, GitLab, and TeamCity.

Note:

  • Jenkins: Requires Jenkins plugin version 7.4 or later.
  • GitLab: Requires GitLab service version 1.1.128 or later.
  • TeamCity: Requires TeamCity plugin version 1.4.4 or later.
CI job

A job that the auto action executes, depending on the selected CI server.
Execution parameters

Job execution parameters that are 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 runs. They are not affected when corresponding values on the 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 the branch as default on the CI server.
Branch name

The branch on which the job runs.

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, the 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 OpenText Core Software Delivery Platform, and default branches are not set on the CI server, the auto action fails.

Back to top

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.

Back to top

REST auto actions

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

There are several related configuration parameters that can be customized as needed. 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 (default: 60 seconds), or specify the allowed URLs using RC_AA_REST_CALL_ALLOWED_URL_LIST. 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:

  1. Select Generic Service > REST Call as the action type.

  2. Define the relevant fields:

    Field Details
    HTTP Method Select an HTTP method: DELETE, GET, POST, or PUT.
    Auth type (Optional) Select API Key to use an API key with the REST call.
    URL Specify a URL.
    Body 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.

  3. (Optional) Click + Add Header to add a header to the API call.

  4. (Optional) Click + Add Line to create a named expression to parse the response.

  5. (Optional) Implement advanced output processing. For details, see Advanced output processing.

REST Poll actions

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 (default: 30).

  • Interval between the polling attempts (default maximum: 1440 minutes, default minimum: 1 minute). The interval is also used for all subsequent polling requests, not just the initial request.

  • Request timeout.

  • REST poll allowed list.

These properties are set by configuration parameters beginning with the prefix RC_AA_REST_POLL. For details, see Configuration parameters.

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.

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 Poll auto action:

  1. Select Generic Service > REST Poll as the action type.

  2. Define the relevant fields:

    Field Details
    HTTP Method Select an HTTP method: DELETE, GET, POST, or PUT.
    Auth type (Optional) Select API Key to use an API key with the REST call.
    URL Specify a URL.
    Body 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.

  3. (Optional) Click + Add Header to add a header to the API call.

  4. (Optional) Click + Add Line to create a named expression to parse the response.

  5. Specify success and failure conditions. Click + Add Value to specify multiple values.

  6. Optionally, implement advanced output processing. For details, see Advanced output processing.

Back to top

Next steps: