The 5.7.2 version of the AWS elastic stack is now available. 🚀

This release includes:

• Upgrade Docker for Linux (20.10.9) and Windows (20.10.7)
• Upgrade docker-compose for Linux (1.29.2) and Windows (1.29.2)

It also fixes:

• BuildkiteAgentTokenParameterStorePath support for AWS Secrets Manager SSM references

For full list of additions, changes, and fixes, see the elastic-ci-stack-for-aws changelog on GitHub.

The 3.33.3 version of the buildkite-agent and the 5.7.0 version of the AWS elastic stack are now available. 🚀

The 3.33.3 Agent release has added:

• Support for unset environment variables in Job Lifecycle Hooks

The 5.7.0 Elastic Stack release has added:

• Support for storing builds, git-mirrors, and Docker data on NVMe Instance Storage
• Retried login for ECR and generic Docker registries
• Experimental CloudFormation service role, listing the IAM Actions required to create, update, and delete the template
• A README feature matrix for Linux and Windows
• qemu and binfmt hooks for cross-architecture Docker image builds
• Support for AWS SSM sessions

For full list of additions, changes, and fixes, see the buildkite-agent changelog and the elastic-ci-stack-for-aws changelog on GitHub.

The 3.32.3 version of the buildkite-agent and the 5.6.0 version of the AWS elastic stack are now available.

The 3.32.3 Agent release has added:

• Support for cross-region artifact buckets
• Improved error logging around AWS Credentials
• Logging to the artifact upload command to say where artifacts are being sent

The 5.6.0 Elastic Stack release has added:

• Cross-region secrets bucket support to git-credentials-s3-secrets
• AssumeRole support in the ECR Login plug-in

For full list of additions, changes, and fixes, see the buildkite-agent changelog and the elastic-ci-stack-for-aws changelog on GitHub.

From 1 October 2021, build artifacts hosted by Buildkite will be retained for six months from time of upload, after which they will be deleted. Artifacts uploaded before 1 April 2021 will also be deleted at this time.

Previously, build artifacts were retained indefinitely, which means we're currently storing over 7PB of data 🤯📈

Custom-hosted build artifacts are not affected by this change, and remain available to any customer who wants more control over their retention.

As always, you can reach out to us with any questions about this change.

We've released v5.5.0 of the Elastic Stack CI for AWS ☁️

Included in this release:

• Template validation rules for the Buildkite Agent token
• Secret redaction in build logs
• Support for the pre-bootstrap Buildkite Agent lifecycle hook

You can read the full release notes on the v5.5.0 release on GitHub.

We've released v3.32.0 of the Buildkite Agent 🦾🤖

The release adds a new pre-bootstrap lifecycle hook which can accept or reject jobs before environment variables are loaded, providing an additional layer of security and control over your Buildkite agents. See the documentation on lifecycle hooks for details on how to use it.

You can read the full release notes on the v3.32.0 release on GitHub. To upgrade, follow the instructions in the Agent docs.

We've released v1.2.0 of the Buildkite CLI 📎💪🏼🪟

Included in this release:

• The bk build create command now has a --meta-data argument, for setting Build Meta-Data when creating a build
• Running local builds (via bk local run) now works on Windows
• An improved GitHub authentication flow

You can read full release notes on the v1.2.0 release on GitHub

To upgrade, if you're using Homebrew on a Mac run brew upgrade bk, otherwise download the latest release for your platform from the GitHub release page.

The latest release of the Buildkite Terraform provider adds buildkite_meta: a data source providing the IP addresses Buildkite uses for webhooks ✨

The new data source can be used in your terraform project to dynamically set firewall and ingress rules, allowing in traffic from Buildkite 🚦

You can find a code sample and attribute reference in the Buildkite provider docs on the Terraform Registry. For more detailed information about the addition, check out the v0.4.0 release on GitHub.

To support customers with inbound network firewalls, Buildkite's Meta API lists the IP addresses that Buildkite uses to send outbound traffic such as webhooks and commit statuses.

To improve network resilience, new IP addresses were added to the Meta API earlier this month. If you use network ACL/firewall rules to allow-list traffic from Buildkite, these should be updated immediately.

During the week of 2021-04-19 traffic will intermittently be switched to the new IPs for short periods as a low-impact method of uncovering issues. During the following week of 2021-04-26 outbound traffic will be permanently switched to the new addresses.

If you only want to build tags, you can now optionally switch off building branches 🚦

We've added a new setting: Build branches that is on by default for new pipelines. To only build on tags, disable Build branches and ensure that your Build tags box is checked:

You can find the Build tags and the new Build branches setting in your pipeline's Repository settings when using GitHub, GitHub Enterprise, Bitbucket, or Bitbucket Server.

We've heard that some Buildkite customers are considering ARM in production, so we've made sure that Elastic Stack for AWS v5.1.0 can help you get there ✨

v5.1.0 adds support for the following AWS instance types with an ARM-powered Graviton CPU:

• m6g.*
• m6gd.*
• t4g.*
• a1.*
• c6g.*
• c6gd.*
• r6g.*
• t6gd.*

To use these instance types, follow the upgrade guide for v5.1.0 and set your InstanceType stack parameter 🚀

Apple machines with the new ARM-based M1 chip are being delivered to Buildkite customers, and starting from agent 3.26.0 we have an experimental binary that will run natively on these systems.

Users with M1 based hardware can install the native binary by:

• Using Homebrew
• Running our curl install script
• Downloading the darwin-arm64 binary directly from GitHub

As part of the transition to GraphQL, we have added graphql_id for the following REST API resources. The graphql_id is used to target specific resources when running queries and mutations on GraphQL API.

• Agent
• Build
• Job
• Organization
• Pipeline
• Team
• User

Here is an example response from pipelines which includes graphql_id:

{
  "id": "849411f9-9e6d-4739-a0d8-e247088e9b52",
  "graphql_id": "UGlwZWxpbmUtLS1lOTM4ZGQxYy03MDgwLTQ4ZmQtOGQyMC0yNmQ4M2E0ZjNkNDg=",
  "url": "https://api.buildkite.com/v2/organizations/acme-inc/pipelines/my-pipeline"
}

If you have any questions or feedback, please let us know in the Forum or send us an email 📨

With the new block step attribute, blocked_state, you can specify what state the build should have when it’s blocked by each block step — green passed, yellow running, or red failed.

When you’ve got a block step that requires user input, having the build look or behave like it's passed isn’t always what you want. Setting blocked_state will affect the build state within the Buildkite UI, source provider integrations, webhooks, and notifications. This gives you more control over how your builds interact with PRs and custom integrations.

Add the new blocked_state attribute to your block steps to change the blocked status colour from the default green.

You can now mix positive and negative branch filter patterns for more precise control over which branches to build 🔀

We've done our best to reach out via email if your pipeline already had a mix of patterns that will be affected by this change 👋🏻

If you're seeing unexpected builds, or are left waiting for a build that isn't showing up, we'd suggest a quick review of your pipeline's branch filter patterns.

For more information on branch filter patterns and some example code, check out the updated branch configuration docs.

We've released a new major version of the Elastic CI Stack 🌈

The latest version includes:

• Experimental Windows Server 2019 support
• Support for four new regions: ap-east-1 (Hong Kong), me-south-1 (Bahrain), af-south-1 (Cape Town), eu-south-1 (Milan)
• Support for managing Agent tokens with AWS SSM
• A blazing fast Agent Auto Scaler by AWS Lambda - up to 300% faster initial scale-ups compares to previous AutoScaling rules

And much, much more! Check out the full changelog for this release on GitHub.

We'd love for you to share any feedback you have on the v5 announcement post in our forum 🤓

Thank you to the many users who provided bug reports and contributions that made this release possible 💚

Debugging job and agent issues has become a whole lot easier with the shiny updates we've just released to the Timeline tab 📖

The new and improved Timeline tab has:

• Live updating with agent events
• Events from the dispatcher showing when the jobs are scheduled and assigned, and
• All your job info in one place including concurrency groups, step dependencies, and conditionals

You can find all of these updates under the Timeline tab of any job 🕵🏻‍♀️

See exactly which repo permissions are requested by Buildkite with our new GitHub App

GitHub Apps create a direct connection between your Buildkite and GitHub organizations, removing reliance on individual user connections. GitHub Organization Admins can then see permissions and manage access on a per-repo basis 🙌🏻

Get started by installing the GitHub App from your Repository Providers page.

We've made it easier to manage multiple source control integrations 🔀 You can now find a list of connected and available integrations on the new Repository Providers page

Click through to each provider for settings and delete options ⚙️

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.