Release Notes v8.6

We released DevSensei | Code Owners for Bitbucket 8.6 on 22 Jul 2025 🎉

Download on the Atlassian Marketplace for Data Center

Features

🆕 DevSensei Workflow Attribute: changed-files

We introduced a new DevSensei Workflow Attribute for changed files. The attribute lets match with a pattern for changed files. Plus it also allows to filter for added, deleted, modified and renamed files.

Why? This attributes lets you implement policies for a specific set of changed files. Example use cases:

• Changed API specification files: Add a comment with a check list.

• Prevent adding the wrong files to a location. For example to transition to a different technology like preventing creating new *.js files while allowing *.ts files.

• Schedule changes for auto merging if only files with texts are updated.

Can you show me an example?

Here is an example devsensei.yaml file that leaves a reminder task when a JavaScript (*.js) file is added:

  - name: Recommend TypeScript for new files 
    conditions:
      - changed-files.added ~= '*.js'
    actions:
      - add-comment:
          task: true
          content: |
            Consider using TypeScript (*.ts) files 
            instead of JavaScript (*.js)

🆕 DevSensei Workflow Attribute: builds

We introduced a new DevSensei Workflow Attribute for builds. The attribute lets you check for successful, failed and in-progress build

Why? This attributes lets you wait for successful builds, react to failed builds or incorporate the build status in merge checks

Can you show me an example?

Here is an example devsensei.yaml file that schedules a bugfix pull request for auto merging only if the builds are successful.

  - name: Auto Merge bugfix when builds succeed
    conditions:
      - source ~= bugfix/*
      - "count(builds.successful) > 1"
      - "count(builds.in-progress) = 0"
      - "count(builds.failed) = 0"
    actions:
      schedule-auto-merge:
        strategy: no-ff

🆕 DevSensei Merge Check: minimun-successful-builds

We introduced a new a merge check for a minimum amount for successful builds. Compared to Bitbucket's own builtin merge checks, you can use DevSensei workflow conditions to customize exactly when checks should prevent a merge

Why? This merge check is a short hand for the common need to check for successful builds.

Can you show me an example?

Here is an example devsensei.yaml file that checks for 1 successful build in on the main branch. And on the release branches it check for 2 successful build, as a extra build process runs for these.

workflows:
- name: Expect successful build for the main branch
  conditions:
    - destination = 'main'
  merge-checks:
    - minimum-successful-builds: 1
- name: Expect successful main build and the release preparation build to succeed.
  conditions:
    - destination ~= 'release/*'
  merge-checks:
    - minimum-successful-builds: 2

🆕 DevSensei Workflow Attribute: author

We introduced a new DevSensei Workflow Attribute for the author of the pull request. It matches against the email or the user slug of the author.

Why? This attributes lets apply a policy depending on an author. For example if a certain change was made by a bot.

Can you show me an example?

Here is an example devsensei.yaml file that requests for an auto merge when the pull request was created by the automation bot.

- name: Auto Merge changes by the Automation Bot, for example depency updates
  conditions:
    - author = automation-bot
  actions:
    schedule-auto-merge:
      strategy: no-ff

Changelog

🐛 Bugfixes 8.6.0 22 Jul 2025

• none

Previous: Release Notes v8.5

Do you have any questions, suggestions, or problems?

Let us know. We’re glad to help!