New feature: Passing parameters between actions

June 5, 2018

New feature: Passing parameters between actions

It's really important to keep your workflow flexible and simple to avoid sleepless nights in the future. Today we're adding another feature that will help you keep your pipelines clean: passing parameters between actions within an execution and passing them between different executions.

How it works

First, we need to define an environment variable, set it as "Settable", and (optionally) enter its initial value:

Adding a new variableAdding a new variable

Now we can set a new value of this variable in every build action:

Command boxCommand box

Such exported variable will be available in further actions and executions with the new value. It seems like a minor feature but it gives you a lot of possibilities and thanks to that pipelines are even more flexible.

Use Case 1: Sending logs in notifications

From now on we can assign a file content to a variable and send it in any notification action. Let's assume we have a log file that we want to send to our Slack channel every time when a build fails.

We just need to set the variable as "Settable" and in "On failed" section assign logs content to its value. After that we send the variable in the notification:

Pipeline examplePipeline example

  • The first action performs the build and saves the results in the logs.txt file
  • If the build fails then the Localshell action will assign content of logs.txt with the export LOGS=$(cat log.txt) command
  • After that we have the Slack action (in which we enter $LOGS)

Slack notification actionSlack notification action

Use Case 2: Semantic versioning

You can also use that feature for versoning of your app. In the environment variable you'll keep the version number which will be incremented on every release.

Add a new variable: VERSION and initialize it with "0". During every release, we automatically upgrade the version via localshell action.

We'll use the version number created in that way when publishing our package. Below you can see an example with pushing the docker image to a registry:

Semantic versioning pipeline exampleSemantic versioning pipeline example

You can use any version format you want. For example, it can use semantic release format 1.1.1, where you separately upgrade the major, minor and patch versions. All you have to do is define settable variables and change their value in a build action (see the example below):

Command boxCommand box

Summary

As we've shown above, this feature can be used to create really advanced pipelines. In the future, it'll be possible to define a condition whether the action should run basing on the results of the previous action.

Recently, we've added some other features that might come in handy—have a look here:

Share:

Alexander Kus

Alexander Kus

Customer Success Manager

A story-teller and conversation-lover, Alexander decided to invest his skills to help his friends at Buddy transform the cold language of patch notes into exciting narratives. Also: an avid gamer, hip-hop DJ, Liverpool FC fan, absentminded husband, and the father of two.