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 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.

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 ✅

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:

```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.

Builds created from schedules will no longer be associated with users 🏃🏼‍♂️💨

If a user loses access to a pipeline, either by leaving the organization or changing teams, you won't need to update your schedules to a new owner.

If your schedule is still attached to a user, you'll see the ⚠️ Requires Migration badge. You'll be able to remove the user from the schedule on the build schedule page.

Unmigrated schedules will have their users automatically removed on the 30th of January, 2020. To check your build schedules, see the Schedules section of your Pipeline Settings 👀

To make it easier to see if you’re running an agent version with a known issue, we've updated the agent list, job timeline, and agent page to show a warning and a link to upgrade instructions 🐛

Upgrade instructions all link to their relevant buildkite-agent GitHub release, so you can dig into the details and find the minimum required version bump.

To make it easier to navigate long build pages, we’ve updated the job navigation so that it sticks to the top of your browser window as you scroll 🔝

Now you can keep your bearings while spelunking through long build output or tracking down that particular artifact 🔍

We've added a new Managing Pipeline Secrets guide to help you understand how to securely store and access secrets, and some of the anti-patterns you should avoid 🔐

Have a read through the recommendations and share it with your team 💪

We’ve added a new multiple property to block steps, giving you the ability to select multiple options when unblocking builds ☑️

When the build is unblocked with multiple selected options, the meta-data value will return the options as a newline separated string.

See the block step documentation for more details and examples.

Your pipeline overview page uses each pipeline’s default branch to calculate the graphs and statistics. We've added support for setting a pipeline's default branch to a blank value (which you can now do directly on the pipelines page), allowing you to see the graphs and stats for all builds in a pipeline 📊

To help you get started with GitHub Enterprise installs that use self-signed certificates, we've added the ability to disable TLS certificate verification in your GitHub Enterprise Buildkite settings 🔓

You can find the new setting in your GitHub Enterprise settings, and read more details in our GitHub Enterprise documentation.

To improve API Access Token security we have removed the “All Organizations” scope from tokens. When managing your tokens you now explicitly select each organization 🔐

If you had tokens with “All Organizations” scopes, they have been automatically migrated and include all of your current organization memberships. When you join a new Buildkite organization, and wish to grant a token access to its data, you must edit the token's settings and select the new organization.

You can manage your tokens on the API Access Tokens Settings page.

We've updated the way times are displayed, and they now respect your browser’s preferred language settings 🌏

For example, if your browser’s preferred language is set to Bokmål or Deutsch, Buildkite will now show 14:17 instead of 2:17 PM ⏰

The Environment Variables documentation has had a major update 🤩

🌈A new layout ⚡️A new section for deprecated variables 🍩Many previously undocumented variables added 💥Expanded descriptions

You can find the updated Environment Variables page under the Pipelines section of the documentation 🚀

We’ve added a new Agent Tokens page to the documentation. It explains default organization tokens, creating and revoking tokens using GraphQL, session token exchange, and more 🕵🏻‍♀️

You can find the new Agent Tokens page under the Agent section of the documentation 🎊

We've been rolling out some big upgrades to Buildkite’s Single Sign-On (SSO) support based on your feedback 📣

The upgrades to Single Sign-On include:

• Admins can now invite users into an SSO organization prior to them joining, along with team membership.
• Team membership can now be passed through as a SAML user attribute.
• Contractors and bots can be added to an organization using any email domain.
• SSO can be made optional for some users, allowing you to have a "break glass" account in the case of your SSO provider being unavailable.
• People can participate in multiple Buildkite organizations with SSO enabled, and easily switch between them.

If your organization hasn't already made the switch, we'll be automatically moving your Buildkite organization to the new version of SSO over the next few weeks. There will be no interruption to your logins, and it won't require any changes to your SSO provider setup.

If you have any questions please email support@buildkite.com, and you can read more about SSO updates in our community forum post 😊

To make testing new pipelines easier, you no longer need to specify the "Message" of a build. Buildkite now automatically resolves the message, based on the git commit, when the build starts 🎉

We've also updated the Builds REST API and GraphQL API so your integrations can take advantage of this too.

We've added a new SSO section to the documentation, with instructions for setting up Single-Sign On with Google OAuth, Okta, OneLogin, and ADFS, and custom SAML providers ✨

You can now also find step-by-step instructions for managing SSO with GraphQL, allowing you to enable, disable and update your SSO settings via the Buildkite GraphQL API