Introducing: New pipeline trigger events

Until now, developers could run pipelines in three modes depending on the workflow type:

• Manually – on click, recommended for production pipelenes.
• Recurrently – on a time interval, useful for integration tests, backups, and website monitoring.
• On push – once a commit is pushed to the selected branch or a branch matching the wildcard pattern, the bread-and-butter mode of any CI setup.

This week, we added two more trigger events:

• Creating a branch, tag, or pull request.
• Deleting a branch, tag, or pull request.

We also added two new default variables:

• $BUDDY_EXECUTION_REF
• $BUDDY_EXECUTION_EVENT_TYPE

Use Case

Let's have a look at how you can apply the new triggers to automatically create, provision, and delete Buddy's sandboxes – dynamic preview environments that require no additional infrastructure to run.

For this use case, we created a pipeline that:

• creates a sandbox for every new branch,
• updates the sandbox on every push to the corresponding branch,
• destroys the sandbox as soon as the branch is deleted.

Image loading...

Let's see how the pipeline is configured and break down the actions one by one.

Pipeline trigger events

The first thing was setting up trigger conditions for the pipeline. The pipeline is run whenever a push is made to any branch in the repository, and whenever a branch is created or removed. The wildcard ensures that the events are restricted to branches only:

Image loading...

Action 1: Create sandbox

This action creates a new environment from the existing base sandbox. The crucial part was setting the tag to $BUDDY_EXECUTION_REF – the tag is used later on to identify to which sandbox the application should be uploaded, and which sandbox should be deleted when no longer needed:

Image loading...

Trigger condition

Each action can be configured to run on certain events, just like the pipeline. This can be done in the Conditions tab. To ensure that the sandbox is launched only when a new branch is created, we used the new variable $BUDDY_EXECUTION_EVENT_TYPE and set the event type to CREATE_REF:

Image loading...

Action 2: Upload files to sandbox

This action uploads the files from the pipeline filesystem to the corresponding sandbox on every push to the repository. But how does Buddy know to which sandbox the files should be uploaded? By identifying the tag of the sandbox, of course:

Image loading...

Trigger condition

To optimize the process, we added a condition that prevents the action to run when a branch is deleted (there's no sense to upload files to a sandbox that will be destroyed anyway). The action will run undisturbed as long as $BUDDY_EVENT_EXECUTION_EVENT_TYPE doesn't contain DELETE_REF:

Image loading...

Action 3: Destroy sandbox

Once the branch is deleted, the pipeline automatically removes the assigned sandbox with the new Sandbox Ops action. The action lets you start, stop, destroy, and snapshot your sandboxes in a convenient fashion. Just like with the upload action, the sandbox to remove is identified by its tag:

Image loading...

Trigger condition

To ensure that the action runs only when the branch is deleted, the $BUDDY_EXECUTION_EVENT_TYPE is set to DELETE_REF:

Image loading...

Summary

And that's it: a proper pipeline that will save your team lots of scripting, so you can do more, get feedback faster, and release more awesome software even faster. What's more, pipeline and action events are not the only way in which you can run your pipelines. Others include webhooks from external services, and Slack slash commands, allowing you to deploy code straight from your favorite messenger service. Look forward for more to come!