Environment variables are pairs of key-and-value commonly used by developers to encrypt authentication credentials, pass values in scripts and hide sensitive data in configuration files.
Today's release expands the feature with a list of default ENV VARs that you can use. The variables are automatically populated during each execution, holding such data as the branch from which the deploy was made or the ID of the execution.
A small yet significant change, this week's update to Run Next Pipeline action will let you optimize your delivery process and release faster in handsome fashion. 😎
From now on, you can force the action to wait until the triggered pipeline has finished, before the original pipeline can proceed with the rest of actions. All you need to do is flip the switch:
FALSE. This means that all queued executions are skipped and only the newest one is run. This was not working for pipelines with the branch assignment set to 'None'. Fixed
ON_EVERY_EXECUTION(default value) to
At the beginning of the year, we made a poll where we asked our customers which feature we should add next.
The winner were on-tag releases & PR support. Today we're delivering the first feature, with the second one following shortly, as the biggest part of the work is already done 😎.
UPDATE: December 2018
After one year of testing, we have decided to shut down the beta of Sandboxes. Using the feedback that we gathered, we are currently working on a new and improved version of the test environment feature. Make sure to follow us on Twitter for news and updates on the release date.
Sandboxes act as stage servers, allowing you to run your application from a chosen branch with just one click.
Every time you make a push to this branch, the application is rebuilt and run afresh. It's a great solution for stage branches because the sandbox will always serve the newest code version.