April 27, 2022
🏗 Feature spotlight: New build actions
If you're a Buddy regular, you surely noticed that the service has been evolving not only in terms of added features, but the looks as well. The new, updated designs have been steadily taking over various parts of the UI. Their spoils so far include pipeline settings, integrations, permissions, sandboxes, variables, users and groups, branches and merge requests, SSH keys, and more.
Below you will find a summary of the latest changes to the second most popular type of actions after deployments: builds.
The first thing that comes to attention is the new, lighter commands field. Here you can enter the commands that Buddy will run on your code, select the script run mode (Bash or sh), and decide whether the action should be mark as failed on the first or the last unsuccessful command:
Here you configure the details of the container in which Buddy runs the tasks defined in the CMD field. If you are using the default Docker image from the Docker Hub, it will be represented with a corresponding icon on the tab at the top:
Of course, you are free to use any other image hosted on Amazon, Google, Azure, or in your very own registry:
Packages & tools have been moved to a dedicated tab, too. This is the place where you install dependencies, tools, and frameworks required by your application. Buddy will run these commands on the first execution, caching the software in the container and making it available for future pipeline runs:
This tab lets you attach databases and services required by your builds. The new tiles on the service selection screen follow the design pattern set by the recent update to the projects list, a glimpse of what you may expect once we finish working on the rest of actions:
Caching lets you mount and manage filesystem paths used to store files between the executions. The tab received a new coat of paint to match other parts of the UI:
This tab lets you manage variables and SSH keys used by the action. After the update, it also contains the list of all default ENV VARs:
First introduced to pipelines, the multi-trigger conditions can now be applied individual builds. This way you can skip the action and shave off another couple of precious seconds from the pipeline execution time:
The last are options which collect miscellaneous settings, such us behavior on failure, number of retries, and the action timeout:
Customer Success Manager