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:
Image loading...
Now we can set a new value of this variable in every build action:
Image loading...
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:
Image loading...
- 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)
Image loading...
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:
Image loading...
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):
Image loading...
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:
Jarek Dylewski
Customer Support
A journalist and an SEO specialist trying to find himself in the unforgiving world of coders. Gamer, a non-fiction literature fan and obsessive carnivore. Jarek uses his talents to convert the programming lingo into a cohesive and approachable narration.