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

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.

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.

The Artifacts API will no longer return the glob_path and original_path fields from 1st September 2019.

When uploading artifacts the Buildkite Agent currently submits information about the glob pattern used to match the artifacts, and where on the filesystem each artifact was stored. We will remove the glob_path and original_path fields from artifacts to reduce the amount of your data we store.

The only place exposing these fields is in the REST API when listing artifacts or retrieving an individual artifact with the Artifacts API. They are not used again by the Buildkite Agent once the artifact is uploaded.

If you rely on this data, please reach out via support@buildkite.com.

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.

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

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

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.

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.

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.

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.