Overview

Steps

Octopus offers two in-built steps which are able to modify a mapped Argo CD application in different ways:

  1. Update Argo CD Application Image Tags
  2. Update Argo CD Application Manifests

Update Argo CD Application Image Tags

This step is responsible for identifying images referenced by an application, and updating their image-tags to the value defined in the Octopus release. This step lets you update the versions of your applications via Octopus, while maintaining the definition of the bulk of your manifests in your Git repository.

You can read more about the update application image tags step.

Update Argo CD Application Manifests

This step is responsible for populating an Argo CD Application’s Git repository with content generated by populating user-provided templates with Octopus Variables.

You can read more about the update application manifests step.

Setting up Git Credentials

Octopus needs to clone and push changes to the Git repositories backing your Argo CD applications. Unlike other Octopus features where you select a Git credential directly, the Argo CD steps automatically determine which credential to use by matching the repository URL from your Argo CD application against the repository restrictions configured on your Git credentials.

Make sure your Git credentials have repository restrictions that include the URLs of the repositories used by your Argo CD applications.

Common Configuration

Some configuration is shared between both of the steps mentioned above, these fields are explained below with the configuration specific to each step on their respective pages.

Argo CD Applications

Argo CD Applications is an aid to help determine which instances, and which applications are going to be updated when executing this step.

Git Commit Settings

The following options provide controls over how we apply the change via Git.

Commit Message

Commit message lets you specify the summary, and description of the change. The description will be automatically populated if left empty.

The content here will be reused for pull request messages if you have selected for the change to merge via pull request.

If the commit summary or description references a Sensitive Variable the deployment will fail. This ensures sensitive data is not leaked to Git via the commit/PR message.

Git Commit Method

Git commit method specifies how changes are applied to your target branch. Either directly committed, or merged via a pull request.

If you decide to open pull requests for your changes, you may choose to do so for all environments or only a specific selection. Environments not selected will commit directly to the target branch.

Currently, pull requests can only be created for GitHub, GitLab, and Azure DevOps based repositories. Please let us know which other providers you would like to see supported.

Step Verification

Step verification options in the process editor

Step verification is available from 2026.1.

There are 3 options for how Octopus will determine your step successfully resolved.

Direct commit or pull request created

Octopus will ensure that the changes were successfully committed to Git, but perform no further checks.

Pull request merged

Octopus will pause the deployment task until all created pull requests are merged. For any environments that do not create pull requests, this will not wait.

Octopus will review this status once every 60 seconds. While the task is paused, this deployment will not count towards your task cap.

Pull request merged verification is available from 2026.2.

Argo CD Application is healthy

Octopus will wait until your Argo CD instance reports that all of the applications are in sync with the created commit and/or pull request, and also reports that all resources are created and healthy.

You can check the current status of your deployment by looking at the Live Object Status page. If the health status is Healthy and the sync status is In Sync, then the deployment will resume after the next evaluation.

Octopus will review this status once every 30 seconds. While the task is paused, this deployment will not count towards your task cap.

Step Timeout (Optional)

When set, this will cause the deployment step to fail if Argo does not report a healthy and in sync status before the timeout period.

Trigger Sync

Enabling this option will cause Argo CD to explicitly sync applications with the changes committed to Git by this same step. This can be done for all environments, or just those specifically selected.

This option is intended to be as close to clicking the sync button in the Argo CD UI as the API makes possible.

Sync Policy

The application sync will be applied using the pre-configured sync options/sync policy for your application.

Information about Argo CD’s sync policies can be found in the official documentation.

Output Variables

When these steps are executed, they each create a number of output variables which contain information relating to the step’s execution, these variables include:

Variable nameContent
PullRequest.TitleThe title of the PR created in the step, empty if no PR was created.
PullRequest.NumberThe unique identifier of the PR within your git repository, empty if no PR was created.
PullRequest.UrlThe Url of the PR created, empty if no PR was created.

These variables will be available for subsequent steps in your deployment process.

Help us continuously improve

Please let us know if you have any feedback about this page.

Send feedback

Page updated on Wednesday, March 4, 2026