Previously when you clicked through a series of jobs in a build, using the browser's back button to step back through the jobs would not always work as expected 👾

We’ve released a fix for the build page browser history list 🛠 the back button will now reliably step back through and expand each job before returning to the previous page.

After 2 years in beta, we are thrilled to promote the YAML Steps editor to our recommended way of managing your pipelines 🎉

After migrating your pipeline to YAML Steps, you can find the new sidebar by clicking "Edit Steps" in your Pipeline Settings ✏️

You can now choose to make the YAML steps editor the default for any new pipelines created in your organization, and we’ve added a migration tool to help org admins get their pipelines switched over.

We'll be announcing deprecation plans for the web steps editor in the coming months, so keep an eye out for the deprecation notice 👋🏻

Enterprise organization admins can now choose to make pipelines read-only, as well as managing the ability to create, edit, or delete at an organization level 🔐

If you’re on the Enterprise plan, you can access these new settings from your Organization's Permissions page. For more information about upgrading your team to Enterprise, get in touch through support@buildkite.com 📨

Skipped builds are now marked as an "error" in GitHub commit statuses:

Build skipping, available from your Buildkite pipeline settings, saves you time by only testing the latest commit on a branch. Previously, a skipped build created a "success" commit status on GitHub, but this could give the false impression that the tests were run and passed.

The options here are pretty limited, but we've made this change to better reflect that the build is no longer pending, but didn't succeed or fail, it finished unusually.

Running another build on the same commit will replace this error status, and running builds on future commits will correctly update a pull request as expected.

We’ve taken some steps to ensure that the Buildkite Agent is ready for upcoming Macs running on Apple Silicon. 👩🏻‍💻✨

First things first, we are eagerly anticipating Go, the language the Agent is written in, gaining the ability to build macOS binaries specifically for Apple Silicon, and plan to provide such binaries as soon as it’s feasible to do so.

Currently we suggest the 64-bit Intel amd64 binary, which happily runs under Rosetta 2 on Apple Silicon. 🦾

For those already adventuring on early Apple Silicon Macs, we’ve verified that our Homebrew-based Mac installation instructions work just fine there. Our non-Homebrew and Linux install script has also been updated to ensure it picks the correct binary on Apple Silicon Macs.

Both of these installation options will install the 64-bit Intel binary, and while the Agent itself will run within Rosetta 2, running an Apple Silicon binary or test suite within your builds should work just fine. We don’t anticipate any obvious issues with this configuration, but please report any issues you do encounter to us.

We have also decided to stop providing 32-bit Intel 386 binaries for macOS as of the next Agent release. This is intended to avoid confusion due to the fact that neither current Macs running macOS Catalina nor upcoming Apple Silicon Macs can run them. For those curious, since early 2018, only the 64-bit Intel binaries have been supplied via our Homebrew formula. If you have a specific need for a 32-bit Intel Mac binary, building the Agent yourself will likely work for the foreseeable future.

To the Linux, BSD and Windows users out there; we have no plans to stop providing 32-bit Intel binaries for your platforms. ✌🏼

If you have any questions we haven’t covered here, or run into some issues in your continuing adventures, please let us know via support@buildkite.com.

We've released a step-by-step guide to setting up automated builds from your Phabricator commits ✨

You can find the Phabricator guide under Integrations in the docs 📚

We've added a new Help menu to Buildkite that combines documentation search, suggested docs for the current page, and a link to support 👋

Check it out now in the top nav of any Buildkite page 🎉

We've added new documentation on how to run Bazel on Buildkite, including a GitHub repository and example pipeline 📗

Check out the new Using Bazel on Buildkite documentation for details, with links to the example repository and further reading.

To make it easier to find and create Buildkite plugins, we've launched the Buildkite Plugins Directory and updated the plugins documentation 🔨

Check out the new plugins documentation, or browse the plugins directory at buildkite.com/plugins.

We’ve rolled out search to the Buildkite documentation site, so it’s easier than ever to find an answer to your questions 🕵🏻‍♀️📚

You can find the search bar at the top of every page of documentation, so it’s always ready to go! 🎉

Stream your data from Buildkite to Amazon EventBridge with our new first-class integration 👩🏻‍🔬

You can route 12 different agent, build, and job events to EventBridge to track custom build metrics, monitor developer wait time, run AWS infrastructure operations based on build events, and create faster autoscaling rules.

You can find Buildkite in the EventBridge partner event sources. Check out our EventBridge integration documentation for detailed setup instructions 📚

We're discontinuing support for TLS 1.0 and 1.1 as part of regular efforts to improve the security of the Buildkite platform. We're making this change on agent.buildkite.com effective immediately. As of 1st March, 2020 we will only support TLS 1.2 and above on buildkite.com and all subdomains.

These older protocols have been on a deprecation track for quite a while. Almost all traffic to buildkite.com is already using TLS 1.2. It has been supported in browsers since 2013, and many browsers will be removing support for TLS 1.0 and 1.1 this year. TLS 1.2 has been supported by the Buildkite Agent since the first v2 release in 2015. If you're also using the Buildkite API please double check that your clients support TLS 1.2.

If you have any questions or concerns please reach out via support@buildkite.com.

Send notifications to email addresses, Basecamp Campfires, or Slack Channels with the new notify pipeline YAML attribute 💎

Add as many notifications as you need for different teams or individuals alongside your pipeline steps in the notify YAML block:

1
2
3
4
5
6
7
8
steps:
  - command: test.sh
  - wait
  - command: build.sh

notify:
  - email: "coolthings@internet.com"
  - slack: "fish-space#general"

For more information about adding notify to your pipeline.yml file, check out the new Notifications guide 💡

Since adding conditionals support we've added the following 11 new variables and one new function 🎉

• build.env()
• build.author.email
• build.author.id
• build.author.name
• build.author.teams
• build.commit
• build.creator.email
• build.creator.id
• build.creator.name
• build.creator.teams
• build.pull_request.draft
• build.source

You can find full descriptions of all the available variables in the Using Conditionals guide, as well as new code samples 💫

Buildkite can send notifications to your favourite Slack channel when your builds have finished. These notifications can be filtered in a few different ways, including to only "failed" and "fixed" builds. Historically, "fixed" meant there was a previous build on the same branch which failed and the new build has passed. Now "fixed" is also sent when a new build becomes blocked.

We've tried to make this change carefully so that existing notifications are mostly unaffected, apart from "fixed" notifications appearing when builds become blocked. If this interrupts your workflow, please reach out via support@buildkite.com.

Previously, the build would consider a timed out job as "failed", regardless of its exit status 🙃

This could sometimes happen if a command finished just as the job was being timed out, or if it had specifically implemented signal handling to gracefully exit.

Now, jobs that timeout with an exit status of 0 will be marked as "passed", so you can depend on the exit status as the one source of truth for job status ✅

We've added support for defining step dependencies in your pipeline configuration, allowing you to minimize the wait times in your builds ⏭

To define a dependency between two steps, you can use the new properties key and depends_on:

1
2
3
4
5
6
7
8
9
10
11
steps:
  - command: "build.sh"
    key: "build"
  - command: "tests.sh"
    key: "tests"
  - command: "upload-coverage.sh"
    depends_on: "tests"
  - command: "deploy.sh"
    depends_on:
      - "build"
      - "tests"

We've also made sure that you can easily transition an existing pipeline to use step dependencies: starting with a sequential pipeline that uses wait steps, you can gradually add depends_on as you need.

For more information about how dependencies work, and how to add them to your pipeline, see the new Managing Step Dependencies guide ✨

You can now more easily embed colored terminal output in annotations. 🌈

Wrap any ANSI formatted console output in a Markdown block with either the term or terminal syntax:

1
2
3
```term
Fancy \x1b[91mc\x1b[33mo\x1b[93ml\x1b[92mo\x1b[94mr\x1b[95ms\x1b[0m here
```

The ANSI formatting is then rendered for you in the annotation:

You can read more about the formatting supported in annotations in the CLI docs.

There is a new feature available on our Enterprise plan: you can now choose to archive build logs to your own private S3 bucket, instead of storing them at rest with Buildkite 📦🔐

To enable private build log archiving for your organization, or to inquire about upgrading your team to Enterprise, email support@buildkite.com ✉️

We've rolled out a fix for an issue where dates we presented in Webhooks were using an unusual ISO8601 format. This didn't match the one we document, or the one the REST API returned.

Previously, Webhooks returned dates like this: 2019-08-26 23:03:00 UTC 🙃

They're now consistent with our REST API, and will be returned in the format 2019-08-26T23:03:00.000Z 🎉