Buddy lets you run delivery pipelines in various modes: manually on click, recurrently on interval, or automatically on push to repository. However, sometimes you may want to run a pipeline but skip certain actions—for example, when the commited changes don’t require to be compiled by the build.
However, it also means websites need to be built and tested before it can be released. A textbook example of a properly configured delivery process can look like this:
Following our recent Kubernetes integration, we’re happy to announce you can now run your containers on Google clusters.
Google Container Engine is a cluster manager and orchestration system run in Google Cloud. It is based on Kubernetes open source container management system and is most often used by software developers for creating enterprise applications that require scalability and performance.
- Trigger conditions in build actions, eg. run gulp on tasks only on changes in the
- New action: Wait for apply. The pipeline will wait for manual confirmation to proceed
- New action: Run Kubernetes job
- You can now optimize your Kubernetes tasks in the Google Container Engine
SFTP, SCP, Rsync, the good old FTP – there are many ways to deliver an app. The choice depends on many factors, such as working speed, infrastructure limitations (some servers allow only FTP upload), or developer preferences.
Some time ago we made an analysis of what our clients use for application upload. The clear winner was the FTP protocol. Right after it, there were SFTP and Rsync. However, in this post we’d like to talk about the fourth contender that only just missed the podium: Git.
- Read what’s coming up in our feature roadmap
- Google App Engine – in this action we’ve been using the offical Google image. Recently, Google has changed the base image to Alpine, which forced us to change the way in which the methods are called
- [Buddy Enterprise] You can now set the timeout for build actions in config. If the length of pipeline execution exceeds the value, the execution will end as ‘failed’
New Relic is a tool that lets you monitor and optimize the performance of your application and production server. It is widely used by thousands of developers across the world, including the Buddy Team.
- Don’t skip flag. A single pipeline cannot be undergoing more than one execution at a given time. In other words, if the execution is in progress and another user runs the pipeline, the second execution will be queued and won’t start until the first one is over. However, if there are more executions in the line (for example 5), Buddy will only run the newest execution (5) and skip the rest (2-4). From now on you can check Don’t skip in the pipeline and Buddy will run all executions one by one. This feature is useful if you want to check every single commit for errors
- You can now parameterize the URL address in the Web Monitoring action with env variables and Buddy parameters
- From now on the errors thrown on the server side by HTTP requests will be covered in a detailed stacktrace in the action logs
- You can now temporarily disable specific actions in the YAML file by adding
"disable: true"to the action properties
- When two or more pipelines were triggered and queued, the pipeline that was triggered last was executed as the first in line. From now on the pipelines will be executed in the natural order they were run.
- One of our clients (cheers Mike!) reported a problem with fetching feeds on the Activity stream. We’ve changed some indexes in Mongo DB and fixed it
- Fixed bug with running pipelines with HEAD revision set fetching the revision from the default branch instead of the branch set in the pipeline
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.
It’s been a busy couple of months for the team at Buddy.
As you can learn from our weekly newsletter, we’re doing our best to drop new features regularly, their priority always reflecting current demand from the community. Here’s a few words on what we’re working on at the moment, and what we’re cooking for the months to come.
- New integration: Kubernetes. You can now apply K8s deployment configs, set images in K8s deployment, and run K8s jobs.
- A followup to using Slack as a deploy bot, it is now possible to run deployments with a short hash code
- You can now use the list of commits and the list of added/modified files in the Buddy parameters. The full list of parameters is available here
- For some users the DigitalOcean integration was not listing droplets when adding a new deployment action. This was caused by the token not refreshing correctly. Fixed
- Fixed bug with Google Cloud Storage deployment not working properly if the source path indicated a single file instead of a folder
- Fixed bug with listing projects in Google Cloud Engine. Just like with DigitalOcean, this was caused by the token not refreshing correctly
- [Buddy Enterprise] Fixed bug with wrong allocation of RAM to Docker containers, which in some cases caused the installation process to fail.