We’ve added the annotations endpoint to our REST API for retrieving a build’s annotations 🗃

The data is presented as rendered HTML (the same HTML we use within the app) within a JSON body, alongside everything else you might want to know about the annotation.

You can read more about this addition in the Annotations API documentation 📖

There’s a whole new section in the docs: ✨Deployments ✨

Here you'll find common patterns for deployments with code samples and walkthroughs, as well as how to add manual approval steps, and working with external deployment systems.

Also new in the deployments section is our guide to Deploying with Kubernetes: a complete walk-through of setting up your Buildkite pipeline to deploy to your Kubernetes cluster

Check it all out in the new Deployments section 📚

We've added new documentation on Buildkite Agent's new Artifactory support for uploading build artifacts to JFrog's Artifactory 🎉

There is now first-class support for uploading your artifacts directly to your Artifactory instance.

To learn more about Artifactory and our technology partnership, head to the JFrog Partner website. To learn more about Buildkite's built-in Artifactory support, see our new Artifactory guide 👀

We've added a new if property that uses a boolean expression to decide whether a step will be run or skipped 💫

You could previously use the branches property to limit the running of a step based on which branch you were building, but this new option allows more complex conditions 😎

steps:
  - label: '💨 Smoke Test'
    command: smoke-test.sh
    if: "build.branch == 'master' || build.message =~ /\\[smoke\\]/i"

The if property is available on all step types; check out the Using Conditionals documentation for details!

We've added a new API Access Audit section in your Organization Settings, so you can identify old and unused tokens, and revoke their access to your organization’s data 🕵️

As well as sorting by usage or age, and searching by scope, you can search for the a full token value — allowing you to inspect and revoke a token you've access to.

You can read all about it in the new Managing API Access documentation, and if you’re an organization admin you can find the new API Access Audit section in your Organization Settings.

The swag you've all been waiting for is finally available in the shop: Buildkite socks 🧦

Our socks are pure cotton and are available in Small, Medium, and Large. Get your hands (or paws🐾) on a pair here: https://shop.buildkite.com/products/socks

We've added a new Single Sign-On section to your Buildkite organization settings, allowing you to setup, test, activate and manage your SSO configuration:

See the SSO documentation for all the details, and how to get started.

We’ve added support for setting the timezone of your Scheduled Builds, so you’re no longer limited to just UTC ⏰

As an added bonus, if you specify a timezone it will automatically handle changes such as daylight savings 🎉

You can read more about the new timezone support in the updated Scheduled Builds documentation.

We've added the ability to link to build annotations, so you can more easily share them with your team, and link to them in your build output 🔗

You can find an annotation's link using the coloured bar on the left, or you can add #annotation-<context> to the build page's URL. For example, if the annotation has the context coverage, you'd add #annotation-coverage to the build page's URL.

See the buildkite-agent annotate documentation for information on adding and updating build annotations.

We've added a pipelineRotateWebhookURL GraphQL mutation for rotating the webhook URL that connects a pipeline with your source control. And a github-webhook-rotate CLI tool for automating the process with GitHub 🌪

You can find the CLI tool on GitHub at buildkite/github-webhook-rotate, and the GraphQL mutation documentation by searching for pipelineRotateWebhookURL in the GraphQL Explorer.

We've added a new set of REST APIs for managing an API Access Token, including the ability to immediately revoke the current token 🗑

See the API Access Token REST API documentation for more details.

To help increase the security between Buildkite and your Github Enterprise, Gitlab Community/Enterprise, or Bitbucket Server, you can now limit which IP address ranges are allowed to send build events to Buildkite 🚧

You can configure the new IP restrictions using the "Allowed IP Addresses" fields in your Buildkite Organization Settings.

To protect accounts from being accessed using compromised passwords, we've integrated haveibeenpwned.com into all of our authentication systems, allowing us to verify that known compromised passwords can't be used to access Buildkite data 🚷

The integration with haveibeenpwned.com uses a technique called k-anonymity hashes, which hashes the password and sends only the first few characters, ensuring there's little risk of disclosing information about your password.

In addition to running builds when code is pushed to GitHub forks, you can now trigger builds when forks are created 🍽🤖

You can use fork events to automatically provision staging environments for example, or to automate other aspects of your fork-based workflows.

Support for the fork event is supported for both GitHub and GitHub Enterprise, and can be configured from your pipeline’s GitHub or GitHub Enterprise Settings.

The latest version of the stack, v4.3.1, introduces a new parameter: EnableExperimentalLambdaBasedAutoscaling. When set to true it will disable the default Amazon-AutoScaling-powered scaling behavior in favor of a Lambda that handles the scale-out.

The result is a much, much faster scale-out and a much simpler scale-in process that no longer requires lifecycled 🎉

For more information on this parameter, check out our Forum post about it: Experimental Lambda-based Scaler.

We've added a new soft_fail property to command steps, so you can ensure that some jobs never fail the build 🎈

steps:
  - label: '💨 Smoke Test'
    command: smoke-test.sh
    soft_fail:
      - exit_status: 1

To ensure you're not swallowing unintended errors, soft failures can be configured to handle specific exit statuses. And if a job soft fails, it'll be marked in the pipeline with a red warning icon, letting you keep an eye on it:

You can read more about the new soft_fail property in the Command Step documentation.

To help debug your dynamic pipeline uploads you can now view pipeline uploads in the job Timeline tab 🆙

We've also made the job concurrency configuration clearer, by including the concurrency group and limit in the "Job created" timeline item:

You can now pipe updates from the Buildkite Changelog directly into your Slack channels, or other team chat tool, using the new Atom feed 🐶🗞

If you use Slack, see Slack’s guide to adding feeds. If you use other tools, or you need the full feed URL, you can access the new feed at https://buildkite.com/changelog.atom ✨

Buildkite pipelines can now made publicly visible, allowing them to be opened up to the world for the first time! 🌏

If you’re an account admin, you can enable read-only public access for a pipeline from the pipeline settings page.

Many customers and projects are already using them, such as Angular.js and Bazel, and we'd love to read any feedback or ideas you might have on our new beta community forum.

Public pipelines are just the first in a series of improvements we have coming for open-source projects—we’re just getting started!

p.s. Did you know we offer free plans for open source projects? 😘

We've been working on a command-line tool for Buildkite for a while. Recently it's been upgraded with a local pipeline runner for testing out pipelines locally on your development machine.

We use this for testing plugins, and quickly iterating on pipelines in development. Secretly, it was just an experiment to use the image support in iTerm 2 for rendering inline custom emojis 😉💥

Download the latest release and let us know what you think.