Finally – the most requested feature in the history of Buddy has landed! Following tag push executions, it is now possible to trigger pipelines from single and forked repositories on pull requests. This means that you can now use Buddy’s pipelines to test PRs and give GitHub the green light for merge!
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.
- Pipelines triggers now support Pull Requests
- Introduction of Default Environment Variables
- Action commands and inputs now support auto-suggest for Environment Variables (
- It’s now possible to switch integrations to a different user when the current integration owner is being removed from the workspace
- Better handling of connection issues between Buddy and Git services: a new activity event will be posted on such occasion with a detailed log
- Retrying a failed execution of a Docker-based action will now clear the old logs
- The ESlint action doesn’t use the pipeline filesystem for installation of ESlint anymore
- A couple of options now require additional password confirmation
- Fixed a bug with reporting commit status of a pipeline execution to GitHub Enterprise not working properly
- Fixed a glitch in browsing a server filesystem when importing files from an FTP server to a new repository
We’re excited to announce that Casandra has just been added to the group of databases that can be used at Buddy. To take advantage of Casandra, just add a new build action or open an existing one, switch to the Services tab and attach Casandra:
- We have completed our security & sensitive data audits for GDPR and implemented changes to be ready for the new data protection regulation
- Improved support of pushes and executions. Until now, if the webhook from GitHub/GitLab/Bitbucket contained no information about who made a push, it was assigned to the owner of the integration. From now on, such events will be marked with dedicated avatars
- The mechanism that fetches the repository to the pipeline’s filesystem has been improved. From now on, the fetch will be made with the owner’s permissions no matter who triggered the execution
- Updated Git version on our build servers to 2.17.0
- Added Ruby version 2.5 to Sandboxes
- Ececutions with ‘Clear cache’ applied that were paused and resumed during the process (e.g. by clicking ‘Retry’ or using the ‘Wait for apply’ action) were cleared of cached files once again. Fixed
- The SSH action in line-by-line mode was not showing logs if the action had failed. Fixed! Thanks David for reporting that! :)
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:
- [Pipelines] Run next pipeline action now has an option to wait until the triggered execution has finished before proceeding to the next action
- [Version Control] It is now possible to switch Git integration. When adding a new project from GitHub, Bitbucket or GitLab, the user gives Buddy access over OAuth. However, there was a problem if the project creator lost access to the repository, e.g. was removed from the GitHub organization. From now on, you can change the authorized user in the Project Options. You can also update the source repository which is useful if the original repo or organization name has been changed.
- [Kubernetes] Run K8s job action now supports parallelism
- [Heroku] You can now run Git commands in Heroku CLI action
- [Docker] Run Docker Container action can now be used in pipelines with the branch assignment set to ‘None’
- [Docker] Run Docker Container action now supports Buddy parameters
- By default, the flag ‘Always run queued execution’ is set to
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
- AWS S3 deployment validation did not include the target path, which produced ‘Access denied’ in case the user did not have access to the bucket’s root. Fixed. Thanks for the heads up, Jack!
- [YAML] Fixed a bug with incorrect YAML parsing if the trigger time was changed from
ON_EVERY_EXECUTION(default value) to
- [Sandboxes] A month ago we introduced user-friendly URL’s to Sandboxes generated from the branch name and repo slug. However, there was a problem if the subdomain generated was longer than 63 characters. We have solved that by cutting longer subdomains.
In response to more and more questions regarding Buddy badges we’re happy to announce that they’ve finally arrived!
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 😎.
- [Pipelines] Tag push support
- [Pipelines] Buddy will now recommend consecutive actions for your pipeline
- [Pipelines] Easier access to commits and files in the pre-execution review
- [Rollbar] Better support of errors returned by the Rollbar integration
- [CodeDeploy] Better support of errors returned by the AWS CodeDeploy integration
- [Enterprise] The limit for sandboxes has been removed
- Fixed a bug with actions in the ‘On back to success’ section not launching if primary actions contained ‘Wait for Apply’