Buddy is built around a couple of simple rules. The most important are:

  1. Stability
  2. Data security
  3. Simple configuration
  4. Speed

This week we focus on the last point with new trigger conditions for your actions and pipelines. For example, you can now configure your actions to build CSS only if there were changes in .saas files since the last execution.

Until today, trigger conditions could be based on two things:

  1. Changesets
  2. Values of ENV VARs

Now, we're adding another two:

  1. Day of week and hour
  2. Revision status in another pipeline

Run pipelines/actions on specific days and hours

Let's assume that our company works Monday to Friday from 9 AM to 6 PM. During the week, the company employs the Continuous Deployment workflow, which means that all commits to the master branch are automatically deployed to the production server. However, if the pipeline is triggered outside working hours, the deployment needs to be confirmed by a senior developer. This is a healthy solution which lets developers tinker with code, run tests and prepare builds, but saves the company from trouble in case an over-caffeinated dev decides to merge his groundbreaking feature at 3 o'clock in the morning.

The delivery process looks like this:

  1. Test changes and build application
  2. Deploy to SFTP server
  3. Restart app over SSH

Delivery pipeline in  BuddyDelivery pipeline in Buddy

The confirmation step is handled by adding an extra action called Wait for approval before the deployment. To make sure the action is turned off during the working hours, all we need to do is uncheck them in the condition settings:

Setting trigger hoursSetting trigger hours

The days and hours are defined in the timezone of the user. You can change the timezone by clicking on the timezone name above the hours.

Run pipelines/actions only if another pipeline in the same revision finished successfully

The most common project setup involves one pipeline to a staging server where all changes are tested, and one pipeline to the production server with the live version of the application. A good idea is to ensure that the revision which is going to be released to production has passed all testing steps on the staging server.

Pipeline in a projectPipeline in a project

In this case, what we need to do is to set a trigger condition that will check the status of the execution in the selected pipeline

Trigger conditions for a pipelineTrigger conditions for a pipeline

Once configured, Buddy will check if the status of the revision in the Staging server. The parent pipeline will only run if the execution has successfully finished.

The production pipeline will NOT run if the revision has not been executed in the staging pipeline, or the status is different than successful.

In case there are multiple executions in the staging pipeline, the trigger condition will always check the status of the last one.

What's next

In the weeks to come, it will be possible to connect various modes of trigger conditions using logical operators (AND, OR).