Skip to content

feat(bitbucket): resolve cloud merge task status - #1577

Merged
potiuk merged 2 commits into
apache:mainfrom
KatalKavya96:feat-bitbucket-cloud-merge-task-status
Oct 10, 2026
Merged

potiuk merged 2 commits into
apache:mainfrom
KatalKavya96:feat-bitbucket-cloud-merge-task-status

Conversation

@KatalKavya96

Copy link
Copy Markdown
Contributor

Summary

Follow-up to #1471 and part of #606.

Bitbucket Cloud can accept a pull-request merge asynchronously with HTTP 202 and return a merge task. #1471 preserved that task metadata, but resolving the task into the eventual landed_ref was left as follow-up work.

This adds a narrow read-only command for that flow:

magpie-bitbucket pr merge-task-status <id> <task-id>

The command:

  • fetches the Bitbucket Cloud merge task-status resource
  • normalizes pending tasks as merge_status=submitted
  • normalizes successful tasks as merge_status=merged
  • extracts merge_result.merge_commit.hash as landed_ref
  • normalizes failed tasks as merge_status=failed
  • keeps Bitbucket Data Center fail-closed for this Cloud-specific endpoint
  • constructs the task-status URL from the configured repository, PR ID, and task ID rather than accepting an arbitrary URL

Test plan

  • focused merge-task-status tests pass
  • full Bitbucket test suite passes
  • Ruff passes
  • mypy passes
  • git diff --check passes
  • repository prek hooks pass, including workspace pytest

@github-actions github-actions Bot added family:tools tools/* family:docs Docs, MISSION.md, READMEs contract:tracker Tool capability: issue / board / label backend contract:change-request Tool capability: proposed-change review + merge gate (PR / MR / Gerrit change) labels Oct 10, 2026
…ailed tasks

The read-only merge-task-status command reused the merge normaliser and
so reported `operation: pull-request-merge`, which a caller cannot tell
apart from a merge submission. The normaliser now takes the operation,
and the status read reports `pull-request-merge-task-status` with the
same merge_status / landed_ref vocabulary.

Also cover the failed path the README documents: FAILED and ERROR task
states normalise to merge_status=failed.

Generated-by: Claude Opus 5
Claude-Session: https://claude.ai/code/session_01GTPsZ5aEE5bUVYqp47Dpvv

@potiuk potiuk left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM — a narrow, read-only command with the task URL built only from configured values and quoted path segments, Data Center failing closed before any request, and CI green.

Two small nits, which I pushed as a follow-up commit on the branch (d4f9bb5) rather than asking for another round:

  • The status read reused the merge normaliser and reported "operation": "pull-request-merge", which a caller cannot tell apart from a merge submission. It now reports pull-request-merge-task-status, with the same merge_status / landed_ref vocabulary.
  • The failed path the README documents is now tested: FAILED and ERROR task states normalise to merge_status=failed.

This review was drafted by an AI-assisted tool and
confirmed by an Apache Magpie maintainer. The maintainer
approving this PR has read the findings and signed off. If
something feels off, please reply on the PR and a maintainer
will follow up.

More on how Apache Magpie handles maintainer review:
Contributing guide.

@potiuk
potiuk merged commit 27dd6cf into apache:main Oct 10, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

contract:change-request Tool capability: proposed-change review + merge gate (PR / MR / Gerrit change) contract:tracker Tool capability: issue / board / label backend family:docs Docs, MISSION.md, READMEs family:tools tools/*

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants