Currently GIT triggers support only the following filters:


There is some ambiguity regarding the BRANCH filter that I would like to address here. Let’s suppose the following scenario:

  • I want all PRs to master to trigger the pipeline (PR opened)
  • I want all commits (push) on master to trigger the pipeline (PR merged)

This is a standard pipeline that manages PRs on the master branch.

To configure the pipeline to behave as I described I would configured the GIT trigger in the following way:

  • BRANCH set to “/master/gi”
  • PULL REQUEST TARGET BRANCH set to “/master/gi”

The resulting pipeline would never be triggered as the current Codefresh configuration would expect the PR to come from master and point on master, i.e. the PR should point to itself.

To my understanding this behavior is indeed intended. A useful case where this could be helpful is where I want only the branch “staging” to merge on master and therefore I set the BRANCH filter to “/staging/gi” et voilà, the pipeline only triggers for PR from staging to master.

This might be an intuitive behavior for repositories that use master/staging/develop/hotfix branches but it is an ambiguous and unexpected behavior for repositories that use Git Flow and only have the master branch + feature/hotfix that get merged directly on master.

I want the pipeline to be triggered only when I want to merge something on master or when I already merged something on master. I don’t want the pipeline to be triggered whenever I change something in the feature branch. This pipeline is intended only for production.

My personal solution to both scenarios is to add the PULL REQUEST SOURCE BRANCH filter. This would allow to honor PULL REQUEST SOURCE BRANCH and PULL REQUEST TARGET BRANCH filters for PRs, while for commits and other actions the BRANCH filter would be honored.

Another solution would be to simply ignore the BRANCH filter for PRs and only honor the PULL REQUEST TARGET BRANCH filter.


You can have multiple triggers on a single pipeline. So if you create 2 distinct triggers with

  1. BRANCH set to “/master/gi” (first trigger)
  2. PULL REQUEST TARGET BRANCH set to “/master/gi” (Second trigger)

you will get the exact scenario that you want. Or am I missing something here? I am happy to offer more clarifications

1 Like

I was making things way too complex for myself.
I didn’t realize I could just configure two separate triggers.

Works like a charm, thank you!

I am glad it worked out. :slight_smile:

Also I think you will find very interesting this article that explains some of the advantages for why multiple git triggers are perfect for microservices.

1 Like