Ctrlk
Sign UpGet a DemoContact Us
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Automated Activities

Learn about automated activities and how to configure them

Automated activities execute without human intervention, enabling efficient and consistent release execution. These activities run automatically when their dependencies are satisfied, allowing releases to progress smoothly through multiple phases without manual steps.

What are Automated Activities?

An automated activity is an activity that encapsulates a pipeline. It executes as part of a process when its dependencies are met, running the underlying pipeline automatically and handling the execution lifecycle without requiring human input.

Pipeline Activities

Pipeline activities are the primary type of automated activities used in release orchestration. These activities encapsulate pipelines by containing or referencing a Harness pipeline that performs the actual work. When the activity executes, activity variables are mapped to pipeline inputs, allowing you to pass configuration and data from the release orchestration layer down to the pipeline execution.

The system tracks pipeline execution status automatically, providing visibility into what's happening at each step. Pipeline outputs can be captured and used in subsequent activities, enabling you to pass data between activities and build complex workflows where later steps depend on results from earlier ones.

Activity Inputs: Passing Data to Pipelines

Activity inputs are values that an activity receives from the release process (from global variables, phase variables, or outputs from previous activities). These inputs are then mapped to pipeline variables so the pipeline can use them during execution.

Defining Activity Inputs

Configure the inputs section in your activity to declare what values the activity expects:

activity:
  id: deploy_activity
  name: Deploy Application
  inputs:
    # Declare activity inputs
    RELEASE_VERSION:
      description: "Version to deploy"
      type: string
      default: "v0.0.0"
    TARGET_ENVIRONMENT:
      description: "Environment to deploy to"
      type: string
      default: "staging"
  pipeline:
    pipeline: org/project/deploy_pipeline
    inputSet:
      variables:
        # Map activity inputs to pipeline variables
        - name: releaseVersion
          type: String
          value: <+activityInput.RELEASE_VERSION>
        - name: environment
          type: String
          value: <+activityInput.TARGET_ENVIRONMENT>

How Activity Inputs Work

The data flow for activity inputs follows this pattern:

  1. Process Input defines the value: When creating a release, you provide values in the process input (either directly as global variables or mapped from previous activity outputs)

  2. Activity receives the value: The activity's inputs section receives the value

  3. Value maps to pipeline variable: The pipeline.inputSet.variables section maps the activity input to the pipeline's variable using <+activityInput.INPUT_NAME>

  4. Pipeline executes with the value: The pipeline receives the mapped value and uses it during execution

Example flow:

Pipeline Variable Requirements

For an activity input to be mappable to a pipeline, the pipeline must define the variable at the pipeline level with value: <+input>:

Without value: <+input>, the variable will not appear in the activity's Pipeline Input Mapping interface.

Always define pipeline variables at the pipeline level (not inside stages) and set them to <+input> to make them available for activity input mapping.

Activity Outputs: Capturing Data from Pipelines

Pipeline activities can capture output variables from pipeline executions. This allows you to extract dynamic values generated during pipeline execution (such as version numbers, artifact URLs, or configuration IDs) and use them as inputs to later activities.

Defining Activity Outputs

Configure the outputs section in your activity to capture pipeline output variables:

Output Expression Syntax

The expression to capture a pipeline output variable follows this structure:

Example:

  • Stage ID: build_stage

  • Step ID: build_step

  • Output variable name: VERSION

  • Expression: <+pipeline.stages.build_stage.spec.execution.steps.build_step.output.outputVariables.VERSION>

Pipeline Output Variable Requirements

For an output variable to be captured, the pipeline step must define it in the outputVariables section:

Test your pipeline manually before creating the activity to verify that output variables are generated correctly. Check the step's Output tab in the pipeline execution view.

Using Activity Outputs in Later Activities

Once an activity captures outputs, those values can be passed to subsequent activities through process input configuration.

Example workflow:

  1. Build activity outputs: ARTIFACT_VERSION = "v1.2.3"

  2. Deploy activity expects input: VERSION

  3. Process input maps: VERSION: <+phase.build.activity.build_app.outputs.ARTIFACT_VERSION>

Go to Passing Activity Outputs for a complete walkthrough.

Example (YAML)

This example shows an activity in a process referencing a pipeline. The activity is defined within a phase and references a specific pipeline that will execute when this activity runs.

Best Practices

Idempotency

Design activities to be idempotent so they're safe to retry without causing problems. Idempotent activities produce no side effects when repeated and deliver consistent results regardless of how many times they execute.

This is especially important in release orchestration where activities might be retried due to transient failures or manual intervention.

Error Handling

Implement robust error handling that provides clear error messages when things go wrong. Use appropriate retry strategies for transient failures, and ensure failure notifications are sent to the right people so issues can be addressed quickly.

Good error handling makes debugging easier and helps releases recover from problems automatically when possible.

Logging

Ensure proper logging throughout the activity execution so you have visibility into what happened. Execution logs should capture the flow of operations, and error details should provide enough context to diagnose issues.

Performance metrics help you understand how long activities take and identify bottlenecks.

Testing

Test automated activities thoroughly before using them in production releases. Unit testing verifies individual components work correctly, integration testing ensures activities work well with the rest of the release process, and failure scenario testing helps you understand how activities behave when things go wrong.

Related Topics

PreviousActivity Types
NextManual Activities

Last updated

Was this helpful?