Skip to content

Conversation

@ywei2017
Copy link

Our bitBucket team upgraded the thing to 7.x and of course, the pipeline was broken this morning.

I took a minimalist approach to make it working again. I read in the discussion board of efforts to make everything API based, so I don't want to change more than necessary, and causing more headache down the road.

Want to put the PR out for review. We will do more testing in the next week or so, and incorporate any fixes that arise.

Would also appreciate other folks to give it more testing.

Thanks

branch=$(echo "$prq" | jq -r '.fromRef.displayId')
fi

# calculate source and target commit
Copy link
Author

Choose a reason for hiding this comment

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

get the info from the API, instead of rev-list

Remove using "rev-list"  to get source/target commit for PRs
Emulate pull-request/*/merge for bitBucket 7

* `only_when_mergeable`: *Optional (default: false).* If enabled only pull requests which are mergeable (all tasks done, required number of approvers reached, ...) will be built.

* `max_pr_to_check`: *Optional (default: 999).* Max number of PRs to check, ordered in descending order by PR number.
Copy link
Author

Choose a reason for hiding this comment

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

Our corporate bitBucket server is pretty slow, and heavily loaded. And it has days REALLY, REALLY slow, so after much hesitation I added this flag. For most people, nothing needs to be done, and a default of 999 is plenty enough. For the rest of us, giving it a limit speeds things up quite a bit.

set +e
PULL_REQUESTS=$(echo "$REMOTES" | grep -E "/pull\\-requests/[0-9]+/${prq_branch}")
PULL_REQUESTS=$(echo "$REMOTES" | grep -E "/pull\\-requests/[0-9]+/${prq_branch}" | \
sort -t / -k 3 -n -r | head -n $max_pr_to_check)
Copy link
Author

Choose a reason for hiding this comment

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

Sort by the PR number and sort in reverse, taking the top $max_pr_to_check ensures we get the most recent ones.

exit 1
fi

if [[ "$branch" == */from ]]; then
Copy link
Author

Choose a reason for hiding this comment

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

If the source branch is /from, we are merging in the changes from the $target_commit so we fake it like /merge'. This is important for the get` steps, which is often followed by the pipeline figuring out "what changed" in the PR? Without this step, the PR will miss the changes on the target branch and show them as altered files.

@asehra
Copy link

asehra commented May 17, 2022

I am facing the same issue, but looks like the repo is no longer maintained.

@ywei2017
Copy link
Author

@asehra Feel free to try my repo. We have done some testing and seems to work fine. But if you find any issues, I will be happy to investigate.

@ywei2017
Copy link
Author

ywei2017 commented Jun 3, 2022

@mmb will you be kindly review the PR? We have gone through quite some testing and I think it works fine to fix the issue.

thanks

@ywei2017
Copy link
Author

@mmb - Any update?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants