Benedetta Dal Canton that's great news! Are there details somewhere on how it would work, or a way to test it yet?

Aaron Burt:

Hi Aaron, there is no way to test it just yet, but I can walk you through the solution we're proposing.

I will preface this by saying that this solution was primarily designed for our Github App integration experience, which is a little different from our oAuth integration because it allows having different pipelines (= different YML files) for different units of work. However, if the feedback is positive, this is extensible to our oAuth experience too.

Just to setup the scene:

You have a CircleCI project

Your project can have as many pipelines as you need - for example you might have 3 pipelines: "unit tests", "e2e tests", "deploy", each defined in a YML file

Each pipeline can have several triggers, coming from different sources (may be repos, third party systems, schedules, …)

In the image below you have a mock-up of the page you’d use to edit your Github trigger specifically.

You have options to subscribe to different types of Github events (push, pull_request, issue_comment), and some "presets" (the buttons) that let you select common scenarios. You can use the presets and/or edit the code in the editors to express more complex conditions if you like.

In this example, for the push event we're applying a filter so that the pipeline will only run when a tag is pushed.

The particular pipeline in the example will also run when a non-draft PR is opened or updated, or if the label "critical" is added, and when a PR comment that matches string "/circleci" is added.

We are hoping that this will provide a lot more flexibility in how you can define when your build shold run.

You would also be able to use the same variables you see here (for example event.action_type, event.issue.pull_request, event.comment.body) to express conditionals inside the config file, using the same conditional syntax available today in config.

I’d love to know:

Do you feel this would address your use case?

Does the UX (using raw logical expressions + some presets) feel natural, or do you find it confusing?

Having seen this, can you think of more use cases where you might find it useful to apply these kinds of filters?

Benedetta Dal Canton thank you for the great explanation, and if I understand it correctly, I can just pick any particular set of GitHub repo events to trigger a particular pipeline.

My case is a common one, deploying a test/demo environment when a user opens a PR. If this system lets me trigger the pipeline when a PR is opened, and also on branch pushes _only if_ a PR is open, I'll be a very happy DevOps critter.

Not quite event from Github (there are quite a few but we plan on supporting all that we think would reasonably be useful to trigger CI - starting from "push" (obviously), "pull request" and "issue comment".

Your case is indeed a common one, so there would even be presets (buttons) available to select exactly that scenario.

But in practice, it would look like this:

("synchronize" is effectively when a push happens while a PR is open)

Benedetta Dal Canton That is everything I could wish for, thank you!

Aaron Burt may I ask a follow up question on this?

We're having some discussions about the best way to interact with this interface. Specifically, we're wondering if ti'd be preferable to have:

For example, this would mean that under the "pull request" umbrella you would have one expression statement for each specific event, e.g.

OR

For example, this would mean that all activity types under "pull request" would be grouped in a single rule.

I'm attaching an image that shows the two options.

In both cases, the UI represents the same set of trigger rules: a pipeline will be run

Would love to know your thoughts!