Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

We released DevSensei | Code Owners for Bitbucket 8.2 on (TODO: REAL DATE)🎉

Download on the Atlassian Marketplace for Data Center

Features

🆕 DevSensei Workflow Action: add-comment

We are previewing a new action to enhance workflows: add-comment, which can either create a task or add a general comment.

Why? You can use this action to request changes be made by the author based on a matching condition, or to leave a helpful comment.

Can you show me an example?

Here is an example devsensei.yaml file, configured to create a task to request the PR author change their source branch name when the destination is a release branch:

workflows:
  - name: Non-Hotfix PR to release
    conditions:
      - source~!=hotfix/*
      - destination~=release/*
    actions:
      - add-comment:
          content: "only branches matching hotfix/* can be made to release/*"
          task: true

🆕 Attributes to use in DevSensei Workflow conditions

You can filter conditions more precisely now with additional attributes: title (PR title), repository-name, and source-head-sha (commit hash of HEAD from the source). These join the previously available source, destination and draft

🆕 Control When Actions Re-run with Edge-Triggering

Starting from this release, DevSensei Workflows now execute actions following an edge-triggering model.

What is edge-triggering?

A Workflow’s actions will only execute when its conditions become met. They will only run for a second time in two cases:

  • either there is a period of time where the conditions are no longer met, and then become met again, forming a new edge,

  • or the condition remains met, but a change occurs in the 🆕 retrigger-on value set.

🆕 Workflow section: retrigger-on

Edge-triggering give you more control over when actions run. You can configure the new retrigger-on section with an optional list of attribute names (the same as in conditions). When the value of one of these attributes changes, it will cause another edge trigger if the condition is already met.

Show me an example

Here is how you would configure a workflow to perform some action whenever a commit is pushed to a PR to the main branch:

workflows:
  - name: Listen to pushes
    conditions:
      - destination=main
    retrigger-on:
      - source-head-sha
    actions:
      - # some-action

In the above example, when a PR is created with destination main, then the action will run because the condition is met. If a new commit is pushed to the branch, but the destination is still main, then the action will run again, because the source-head-sha attribute will change value.

Here is what you would see on a PR where the workflow is active:

Screenshot 2024-12-17 at 15.29.25.png

Why a new section?

A new section gives a clear distinction between two concerns: “what state should the PR be in to run an action” and “when should the action run”. Note that retriggers are an optional addition, and not required for the initial action run. i.e. actions will always run whenever the conditions become true.

Breaking Changes

Change to When add-codeowners Action Runs

Due to a change in semantics, users who previously migrated from CODEOWNERS to devsensei.yaml (all versions since v7.0) should add a condition to filter on non-draft PR, and add retriggers for destination and source-head-sha. This ensures that add-codeowners action will run on each destination branch rescope, commit push, or when the PR is no longer draft.

For example:

workflows:
  - # rest as before
    conditions:
      - # some existing condition
      - "!draft"
    retrigger-on:
      - destination
      - source-head-sha

Reviewers are no longer removed on draft PR creation

Code Owners fills out the reviewer list by default. When creating a Draft pull request (since Bitbucket 8.18) these Code Owners are then assign. In previous versions Code Owners removed the code owners from drafts. However, this lead to unexpected behavior that even manually crafted reviewer lists got removed on creating. Therefore, this feature was removed.

Improvements

  • The Auto-Merge History Comment now also contains the time-zone information, in case users' time zones are different from the Bitbucket instance one

  • For Bitbucket version below 9.1, DevSensei will not try to auto-merge anymore when a Code Insight report is created but does not impact your pull request. This is both a performance improvement, as well as reducing the Auto-Merge History Comment size.

  • Schema for devsensei.yaml file for use in IDE now provides hints where to look in documentation for each section.

  • Provide suggestions for attribute names in error messages when user configures incorrect/unknown names.

Bugfixes

  • Fixed: UI elements failed with permission errors when the pull request was created from a private fork.

  • Unlicensed users in Bitbucket groups and reviewer groups are silently ignored instead of producing an error. These groups are maybe maintained by a different team and cannot be easily fixed in the configuration itself.

  • Better error message when there is a blank devsensei.yaml file - or when YAML aliases can not resolve to an anchor.

Previous: Release Notes v8.1

Do you have any questions, suggestions, or problems?

Let us know. We’re glad to help!

 

  • No labels