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
π
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 π
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 π
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 π
1 2 3 4
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.
Create an account to get started with a 30-day free trial. No credit card required.