Bitbucket

Two distinct products behind one provider โ€” pick the variant:

cloud (bitbucket.org)server (Data Center)
commit_statusโœ…โœ…
pr_commentโœ… (+ mode: upsert)โœ… (create only โ€” upsert falls back with a warning)

Authentication

Cloud โ€” username + app password, or OAuth2:

scm:
  bitbucket:
    - name: bitbucket
      variant: cloud
      enabled: true
      auth:
        username:
          secretRef:
            name: bb-creds               # key: username
        app_password:
          secretRef:
            name: bb-creds               # key: app_password
        # or oauth2: { client_id, client_secret, token_url }
        #   grant_type defaults to client_credentials; refresh_token also supported

Server:

    - name: bitbucket-dc
      variant: server
      enabled: true
      base_url: https://bitbucket.company.example.com
      auth:
        secretRef:
          name: bb-token                   # key: token (HTTP access token)

Required annotations

scm.provider = instance name; scm.commit-sha; Cloud: scm.repo-workspace (or repo-owner) + scm.repo-name; Server: scm.repo-project + scm.repo-name; scm.pr-number for comments.

State mapping

pending/running โ†’ INPROGRESS, success โ†’ SUCCESSFUL, failure/error โ†’ FAILED, canceled โ†’ STOPPED (Cloud) / FAILED (Server, which has no stopped state). The status key is the scm.context annotation (default tekton-<run-name>).

Comment templates

PR comment bodies are optional templates: inline string, configmapRef: {name, key}, or omitted for the built-in "Build <State> for <RunName>" body. The chart ships bitbucket-comment.tmpl as an opt-in configmapRef example. See Actions โ†’ Comment templates are optional.