โ€Œ
Beta

Failing builds fast

Today we're introducing a new "failing" build state for faster feedback ๐Ÿƒโ€โ™‚๏ธ๐Ÿ’จ

A build with a job which fails early and makes the build appear to be failing while the rest of the jobs runs

We know it's frustrating when your build fails. But when it does, you want that information as soon as possible so you can get it green.

Now, as soon as a single job fails, the build can be marked as "failing". You'll see a GitHub Commit Status, or a Slack notification โ€”ย whatever your team uses โ€”ย as soon as we know your build is going to fail. And on the dashboard your build will show as failing. If you're using annotations or Test Analytics then your build can also tell you what to do to fix the problem while it's still finishing.

But fast feedback is only half of the equation. There's nothing worse than a build which takes forever just to tell you it's broken. If you're in a big team running lots of builds, running the rest of a failing build might be a waste of time. So we're also introducing "cancel on build failing."

steps: - command: bundle && bin/rails spec parallelism: 100 cancel_on_build_failing: true

Adding the cancel_on_build_failing: true attribute to your command steps will cause those jobs to be canceled as soon as a build becomes failing. That way your agents can move on to the next piece of work. But we'll still send failing notifications before cancelation is complete.

We realise that some folks might need to update API clients or adjust pipeline and workflows, so this new feature is being introduced as opt-in for a smooth migration path. But you can turn on failing builds right now by going to your pipeline on the Buildkite dashboard, then going to the Settings page, Builds, and enabling Fail Fast:

Fail Fast configuration panel with "Enable Fail Fast" button

You can also turn this on for your whole organization on your org's Pipeline Settings page.

The buttons will go away and the feature will be enabled for everybody on Monday, 5th September, 2022.

If this does exactly what you need, or you have a suggestion, we'd love to hear from you in our community Slack channel, or drop us an email to support@buildkite.com.

Samuel

โ€Œ
Beta

Test Analytics private beta

Identify, track, and fix problematic tests with โœจTest Analyticsโœจ, now in private beta.

test-analytics_cover.png

๐Ÿ” Identify flaky tests: See which tests are most disruptive with automatic flaky test identification and analysis over time.

๐Ÿ‘€ Monitor speed & reliability: Get alerts when slow tests are introduced.

๐Ÿ“ˆ Deeply analyze performance: First-class framework integrations provide in-depth performance analysis, helping you find external dependency bottlenecks and more.

๐ŸŽ View real-time results: Watch your test suite run in real-time and get immediate performance insights.

Learn more and join our waitlist at https://buildkite.com/test-analytics.

Michelle

โ€Œ
Beta

Share git checkouts with the git-mirrors Agent experiment

Teams with large repositories, we'd love for you to try out the git-mirrors experiment flag, available on all agents v3.10.0 and above. This enables you to have a single git clone per host, to help speed up git operations and reduce network and disk usage ๐Ÿ‘ฏ

git-mirrors.png

You can get started using git mirrors by setting the git-clone-mirror-flags experimental agent config option.

Let us know about any questions or issues on the Shared Git Checkouts topic in the Buildkite Community Forum ๐Ÿ“

Harriet

โ€Œ
Beta

New in the Elastic Stack: Experimental Lambda-based Scaler

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.

Harriet

โ€Œ
Beta

Defining Pipeline Build Steps with YAML

We've just shipped a new beta feature giving you the ability to define your initial build steps using the same pipeline YAML format that you use in source code.

This means that you can now configure trigger steps, block steps with input fields, and plugins independently of your pipelineโ€™s source repository. YAML steps will become the default for all new pipelines once the beta is complete.

yaml-screenshot.png

Head on over to your "Pipeline Settings" page to convert your pipeline to YAML Steps.

You can read more about the feature and give us feedback in the Buildkite Community Forum

Keith