Trigger Pipelines using Git Events

Updated 2 months ago by Michael Cretzman

You can trigger Pipelines in response to Git events automatically.

For example, when a pull request or push event occurs on a Git repo, a CI or CD Pipeline can execute.

Triggers enable event driven CI/CD and support the practice of every commit building and/or deploying to a target environment.

For general Triggers reference, see Triggers Reference.

In this topic:

Before You Begin


  • Currently, Harness supports Git-based Triggers for the most common Git providers. Harness includes a Custom Trigger for other repo providers.

Visual Summary

Here's a two minute video showing you how to create and run a Trigger in response to Git events.

Step 1: Add a Trigger to a Pipeline

Open your Harness Pipeline in Pipeline Studio.

Click Triggers.

Click New Trigger.

Click one of the Git-based Trigger types. In this example, we'll use GitHub.

Step 2: Set up Webhook Listener

Enter a name for the Trigger.

In Payload Type, select your Git provider. This setting is populated with the provider you selected automatically.

Select or create a Connector to the Git account for the Trigger repo. See Code Repo Connectors.

  • If you set up an account-level Code Repo Connector: in Repository Name, enter the name of the repo in the account in the Connector.
  • If you set up a repo-level Code Repo Connector: the repo name cannot be edited.

In Event, select the Git event for the Webhook.

If the event you select results in the Actions settings appearing, select the actions for the Webhook or select Any Actions.

For details on these settings, see Triggers Reference.

For details on the payloads of the different repo Webhooks, see GitHub Event Types & Payloads, Bitbucket Event Payloads, and Gitlab Events.

Option: Auto-abort Previous Execution

Use this option if you want to override active Pipeline executions whenever the branch is updated.

If you select this option, when the branch you specified in the Connector is updated, then any active Pipeline executions using the branch and this Trigger are cancelled.

The updated branch will initiate a new Trigger execution.

Option: Set Trigger Conditions

Conditions specify criteria in addition to events and actions.

Conditions help to form the overall set of criteria to trigger a Pipeline based on changes in a given source.

For example:

  • Execute Pipeline if the source/target branch name matches a pattern.
  • Execute Pipeline if the event is sent for file changes from specific directories in the Git repo. This is very useful when working with a monorepo (mono repository). It ensures that only specific Pipelines are triggered in response to a change.

Conditions support Harness built-in expressions for accessing Trigger settings, Git payload data and headers.

JEXL expressions are also supported.

For details on these settings, see Triggers Reference.

Conditions are ANDed together (boolean AND operation). All Conditions must match an event payload for it to execute the Trigger.

Step 3: Set Pipeline Input

Pipelines often have Runtime Inputs like codebase branch names or artifact versions and tags.

Provide values for the inputs. You can also use Input Sets.

Click Create Trigger.

The Trigger is now added to the Triggers page.

Review: Automatic Webhook Registration

When you create or edit the Trigger Harness registers the webhook in your Git provider automatically. You don't need to copy it and add it to your repo webhooks.

Step 4: Test Trigger

Make a change on the repo and see if it executes the Trigger. For example, change a file, commit it on a branch, and make a pull request.

In your Git provider repo, you can see that the request and response were successful.

In Harness, view the Pipeline execution.

In Harness CI, click Builds.

You can see the source and target branches. You can also see the pull request comment and number.

Click the pull request number and it opens the Git provider repo at the pull request.

If you open the Trigger in the Pipeline you will see a status in Last Activation Details.

Activation means the Trigger was able to request Pipeline execution. It does not mean that the Webhook didn't work.

See Also

Please Provide Feedback