Product updates - 👋 flaky test, introducing Pilot 👩✈️, audit logs and more
Get early access to flaky test management and Aviator Pilot
🚀 Flaky test management - beta access
🚀 Introducing Aviator Pilot
🚀 Slash commands to specify affected targets
🚀 Configuration audit log
Flaky test management - beta access
What it does:
Connect with your CI to automatically detect most disruptive flaky tests
Configure a status check on GitHub that suppresses flaky tests. This works with Aviator merge queue to reduce your rerun burden
Run automatic nightly builds to track new flaky tests
Learn more here. If you are using CircleCI or Buildkite and want to try out FlakyBot, reply back.
Introducing Aviator Pilot
We understand that every team has a unique way of managing dev workflows. So we are building a configurable automation framework called Pilot! Things you can do with Pilot:
Build your own rules for multi-queue dispatch, emergency fixes, priority queues
Take custom actions on forked PRs or based on author’s GitHub teams’ membership
Send Slack notifications to specific users on custom events
Interested in early access to try out Pilot, reply back.
Affected targets slash commands
Now you can specify affected targets using slash commands. This is very helpful if you want to define introduce multi-queues within your workflow. Learn more.
Configuration audit log
Now Aviator captures any changes to your Merge rules configuration via UI or GitHub config file. You can see changes to your Aviator configuration right from our Merge Rules page in the UI.
A couple of things to note here:
Changes made by Github users will have the Github username and a link to the base branch commit that introduced the configuration change
Changes made by Aviator users from the UI just store the aviator username (which typically will be an email)
Bug fixes and improvements
Now you only need to apply a single label to merge with custom behaviors. For e.g., if you only apply a skip label or a rebase-override label, that will also notify Aviator to queue the PR while handling the custom behavior.
To stay consistent with how Github treats statuses, we now treat
skippedas a success status. If you want to override this and use
skippedas a failure status, you can use our
required_checksconfiguration. See docs.
Fixed auto-requeue issues for PRs with merge conflicts
Fixed rebase for forked repos
Stacked PRs improvements