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.
- [Sandboxes] Manual mode
- [Cloudflare invalidation] Sometimes Cloudflare’s API was unreachable so since now the action takes 3 invalidation attempts with a 5-second interval. If all actions still fail, the action ends with ‘Failed’ status
- [Optimization] The application has been optimized for RAM usage in the client’s browser
- [Private Git Hosting] Improved support for errors’ output when fetching repo from private Git hosting. From now on, the error description will allow you to diagnose the issue yourself without the need to contact support
- [SSH] During the connection validation, we now check whether BASH is available on the server (if you chose this shell in the action settings)
- [Buddy Enterprise] Improved settings division and properties description
- [Buddy Enterprise] You can now define the maximum file size that can be committed to the repo (until now it was 100MB)
- [Sandboxes] If you were using your own Docker image with no bash shell, ‘Browse’ in the Sandboxes was throwing an error for binary files
- [Pipelines] Fixed a bug with actions in the ‘On back to normal’ section being executed even when they were disabled
New Features [Limited Beta]
Tag pushes (coming March 27, 2018)
Pull request executions (coming April 2018)
- [Kubernetes] Overwrite/Cascade and Validate flags are now set to true by default in the Apply Deployment action
- Opening a stacked view now always display the name of the parent project on the top navi-bar (e.g. when opening an element from the global Activity stream)
- AWS ElasticBeanstalk and CodeDeploy actions now support ENV VAR in the source path
- Improved support for
.gitignorein Deployment from Heroku/Azure and Git Push actions. All of them now deploy artifacts and code processed in previous actions by default
- [Enterprise] You can now set maximum size for files commited to the repo
- [Enterprise] Added a validator for GitLab integration that will check for the protocol in the URL to the GitLab instance
- Fixed a bug witch cloning a pipeline with two Wait for Apply actions that was causing the app to crash
- Generating pipeline statistics in large projects no longer causes timeouts
- Opening details for a commit that was previously removed from the repo now produces an error
CI/CD Stories are articles in which we show how companies use Buddy to optimize website delivery.
A significant part of our clients are small and medium webshops who don’t need complicated enterprise software. For them, simple and lightweight Buddy is the perfect DevOps tool.
One of such companies is Druid, a software house from Helsinki, Finland. In addition to regular druid stuff (blood magic, shapeshifting to bears, summoning golems, etc.) the team specializes in Drupal websites and projects.
- The Eslint action now supports custom configs
- You can now use
\(backslash) to enter multi-line commands in the Environment Customization tab
- The comment field in the execution run has been brought to front from ‘More options’
- [Sandboxes] If the indicated SQL dump file is no longer in the repository, Buddy will show you a warning in the logs
- [Sandboxes] Support for Webpack v4.0.0
- [Sandboxes] Removing a branch now also removes the assigned sandbox
- [Sandboxes] Fixed WP Theme & Plug-ins stack
- Sometimes deleting a pipeline would produce errors in other browser tabs where the pipeline was active
We’ve been on fire with Docker lately and we don’t think of slowing down 🔥
Two weeks ago we added the Run Docker Image action. Today, we ship yet another one: Push Docker Image to Registry.
As you know, the deploy mechanism in Buddy is based on changesets.
This means that only new and changed files are deployed to the server. Plus, if a file is deleted from the repository, it will also be deleted from the remote. Unfortunately, the last part wasn’t true for deployments from the filesystem, which was not “aware” of deleted files. Until today.
Docker containers are the natural environment to many different Buddy actions.
No matter if you run commands in the Local Shell, build a Node application, test a PHP website, or compile Java – they all use Docker containers as their running environment.
- New action: Docker Push
- Upgraded deployments from pipeline filesystems with added support for deleted files
- New BASH mode in Docker container-based actions (ex: Local Shell, Node.js, Java, Gulp, etc.)
- Atomic deployment templates have been updated, covering new additions to the SSH action
- [Buddy Enterprise] It’s now possible to manually set the number of available pipeline concurrent executions
- [Run K8s Job] New option: Don’t wait for the job to finish before proceeding
- [Run K8s Pod] New option: Don’t wait for the operation to finish before proceeding
- Frequent deletion of branches was causing glitches to
- If there was no info who pushed the branch in the web hook from GitHub, the branch did not show up on the list in Buddy
run_as_scriptin the SSH action
- Cloning a sandbox didn’t set the proper name for the new one (Thanks Cameron!)
When the idea of Buddy was shaping, our desire was to make a Continuous Delivery tool that will be easy to set up, but also flexible.
Today we’re adding another brick that will let you customize your pipelines even more: the possibility to parameterize your execution.
Since version 2.1.19 you can also parameterize executions via API.