Add support for bitbucket datacenter pull request event merged

[mluckam]

Feature request

Bitbucket Datacenter has 14 supported pull request events:

• pr:comment:added
• pr:comment:deleted
• pr:comment:edited
• pr:declined
• pr:deleted
• pr:from_ref_updated
• pr:merged
• pr:modified
• pr:opened
• pr:reviewer:approved
• pr:reviewer:needs_work
• pr:reviewer:unapproved
• pr:reviewer:updated
• pr:to_ref_updated

Of these 14 pull request events, 4 are currently supported by the PaC provider bitbucketdatacenter:

• pr:comment:added
• pr:comment:edited
• pr:from_ref_updated
• pr:opened

See Atlassian documentation for more information on pull request events.

Some of the events do not make sense to trigger a build such as below:

• pr:comment:deleted
• pr:declined
• pr:deleted
• pr:reviewer:needs_work
• pr:reviewer:unapproved

That being said, it is the responsibility of PaC to determine what event types make sense or instead should PaC implement all provider events and allow the end user to determine which events to utilize? At a minimum I would suggest the following be implemented:

• pr:merged
• pr:modified
• pr:reviewer:approved

Use case

The use case in mind is for the pull request event merged. When a PR is approved and then merged to the main branch, the desire is to trigger a main branch build to have the latest compiled, possibly deployed, and tested. Since this event is not currently implemented it requires an additional PipelineRun defining on-target-branch as main and on-event push.

Current implementation

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  generateName: foo-bar-pipeline-pr-run-
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/*]"
    pipelinesascode.tekton.dev/on-event: "[pull_request]"
...
---
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  generateName: foo-bar-pipeline-merge-run-
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]"
    pipelinesascode.tekton.dev/on-event: "[push]"
...

Proposed solution

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  generateName: foo-bar-pipeline-pr-run-
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/*]"
    pipelinesascode.tekton.dev/on-event: "[pull_request]"
...

[theakshaypant]

Thanks @mluckam for opening this issue and even creating a PR to address it.

requires an additional PipelineRun defining on-target-branch as main and on-event push.

Before even looking at the linked PR, I would like to point out that this is not necessarily true. If you want to run the same PipelineRun for both these triggers, you can use the on-cel-expression annotation. It provides advanced event matching exactly for scenarios like this.

Combining the two PipelineRun triggers you shared earlier, you can combine them into a single trigger as

  pipelinesascode.tekton.dev/on-cel-expression: |
    (event == "pull_request" && target_branch.matches("refs/heads/.*")) || (event == "push" && target_branch == "refs/heads/main")

This would work seamlessly, without any changes in PaC.

As for adding support for the 3 triggers (at minimum) you mentioned (merged, modified and approved), I would like to better understand the use cases for

• modified: Per the Atlassian documentation you have shared, this is triggered when PR title or description is modified. What kind of PipelineRuns do you envision this to trigger?

Will share my thoughts on the implementation separately. :)

[mluckam]

Appreciate the quick responses. Based on the feedback received from this feature request and associated PR, the pull request events modified and approved are not desirable to implement. Given that I do not have a current use case for them, these can be removed from further consideration.

As for the event merge, this pr comment describes how event merge cancels in progress PRs in other providers. If I understand correctly, this PR should implement the above described funcationality for the provider bitbucketdatacenter.

[theakshaypant]

You might have also seen this comment from @zakisk

we don't support PullRequestClosed in PipelineRun matching

I want to make sure we're on the same page about what mapping pr:merged to PullRequestClosed actually does, because it does not solve your original use case.

What PullRequestClosed does today is when any provider sets TriggerTarget = PullRequestClosed, the system takes this path that cancels all in-progress PipelineRuns belonging to that PR and returns, no new PipelineRuns are created.
This is the behavior for GitHub, GitLab, Bitbucket Cloud, and Gitea today. The purpose is cleanup: if CI is still running when a PR is merged or declined, cancel those now-irrelevant runs.

Your original request

When a PR is approved and then merged to the main branch, the desire is to trigger a main branch build to have the latest compiled, possibly deployed, and tested.

to "run pipelines on close (or merge)", is already tracked in #1567 and doesn't exist for any provider yet. PR #2193 attempted it previously and was closed without merge.

For your use case today, the CEL expression approach from my earlier comment remains the cleanest path:

pipelinesascode.tekton.dev/on-cel-expression: |
  (event == "pull_request" && target_branch.matches("refs/heads/.*")) ||
  (event == "push" && target_branch == "refs/heads/main")

This gives you a single PipelineRun definition that covers both pull request and post-merge CI, using the existing repo:refs_changed (push) event and no provider changes needed.

[zakisk]

@mluckam I agree with Akshay if your use case is only to have single PipelineRun for both pull_request and push then you can have that in your target annotation (may be simpler)

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  generateName: foo-bar-pipeline-pr-run-
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/*]"
    pipelinesascode.tekton.dev/on-event: "[pull_request, push]"

I don't still understand use case for pr:merge event. OR Do you want us to implement cancel-in-progress for bitbucket data center?

[mluckam]

@theakshaypant thank you for providing the cel expression and guidance on the proper way to achieve my goal. I do understand that merge is not the appropriate strategy to do so.

It does sound like merge should implement cancel-in-progress for bitbucketdatacenter as it does for other providers within PaC. Since my initial assumption was incorrect, I thought this would be the appropriate direction to take this feature request to implement merged. Please let me know if this in not correct.