Resolve bitBucket 7.x Issue #22
Conversation
pull-request/#/merge branch is gone wiht bitBucket 7.x
| @@ -150,6 +142,20 @@ if [ "$prq" != "NO_SUCH_PULL_REQUEST" ] && \ | |||
| branch=$(echo "$prq" | jq -r '.fromRef.displayId') | |||
| fi | |||
|
|
|||
| # calculate source and target commit | |||
There was a problem hiding this comment.
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
| @@ -72,6 +72,8 @@ It will accept a regular expression as determined by [egrep](http://linuxcommand | |||
|
|
|||
| * `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. | |||
There was a problem hiding this comment.
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.
| @@ -60,7 +61,8 @@ fi | |||
| # collect all pull requests from uri | |||
| REMOTES=$(git ls-remote "$uri") | |||
| 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) | |||
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
|
I am facing the same issue, but looks like the repo is no longer maintained. |
|
@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. |
|
@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 |
|
@mmb - Any update? |
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