jenkinsci/bitbucket-branch-source-plugin

More than 200 branches - build stuck

swolf opened this issue · 7 comments

swolf commented

Jenkins and plugins versions report

Environment

Jenkins: 2.401.1
OS: Windows Server 2019 - 10.0
Java: 11.0.19 - Eclipse Adoptium (OpenJDK 64-Bit Server VM)

cloudbees-bitbucket-branch-source:805.v7f97d29dc0f5

What Operating System are you using (both controller, and any agents involved in the problem)?

OS: Windows Server 2019 - 10.0 (controller, it never gets to the agent)

Reproduction steps

  1. Have a bitbucket repository with more than 200 branches
  2. Have a default branch called 'master' and try to build it

Expected Results

Build is running without any issues.

Actual Results

Build is stuck at the very beginning when it is querying the branches from bitbucket. The only output would be for example: "Branch event" and after a few hours when nothing further happened an error is thrown.

Anything else?

We further investigated the issue and it seems to be a problem with the pagination of the branches. When we have less than 200 branches (default page size is hardcoded to 200:

) it is working as expected.

A REST query to bitbucket with the following GET paramaters is the starting point: mybitbucket.com/rest/api/1.0/projects/TS/repos/myrepo/branches?start=0&limit=200

This works as expected. Looking at the code it seems to try to go to the next page:

private <V> List<V> getResources(UriTemplate template, Class<? extends PagedApiResponse<V>> clazz) throws IOException, InterruptedException {

Apparently, the last page is never reached and bitbucket is flooded with requests. Similar requests like this one are done every 20ms until the job is failing (bitbucket access log):

x.x.x.x | https | xxx | my_jenkins_user | 2023-06-13 07:31:18,875 | "GET /rest/api/1.0/projects/TS/repos/myrepo/branches HTTP/1.1" | "" "Apache-HttpClient/4.5.14 (Java/11.0.19)" | 200 | 0 | 7018 | - | 29 | - |

I don't see anything obviously wrong with the loop in getResources.

Does it query the second page from the correct URL (with ?start=200&limit=200) but then fail to realize that it got the last page? You could perhaps find that out by setting up Apache HttpClient logging at the Jenkins controller.

Which version of Bitbucket Server is this?

swolf commented

Does it query the second page from the correct URL (with ?start=200&limit=200) but then fail to realize that it got the last page? You could perhaps find that out by setting up Apache HttpClient logging at the Jenkins controller.

I tried to activate the log recorder but did not get any output. Can you give me a hint what to enter? This did not log any requests (entered as logger): org.apache.http.impl.client

It is only NOT working for the master branch in our example.

Which version of Bitbucket Server is this?

Bitbucket version is 8.10.1

Thanks for your support.

If you add the "Discover tags" behaviour to the branch source, then the plugin uses the same getResources method for tags too. However, we have repository with over 400 tags and the plugin has no problem listing those. We are using an older version of Bitbucket, though.

swolf commented

I got the logging enabled in the jenkins with this logger: org.apache.http.wire

Then I see the following requests flooding bitbucket (always the same):

http-outgoing-3216760 >> "GET /rest/api/1.0/projects/myproject/repos/myrepo/branches?filterText=master HTTP/1.1[\r][\n]"

It seems that there are no pagination GET Parameters (limit and start). Bitbucket has a default limit of 25 entries and there are more than 25 branches containing the word master. This is probably the issue we are facing.

It seems that the url does not contain the GET parameters for limit and start at all (I am not so familiar with this Handy URI Templates):

I looked at the Bitbucket Server REST documentation today and IIRC there was a parameter for sorting exact matches to the beginning of the list. Even if this bug is fixed by adding the start and limit parameters to the URI template, it could be useful to add the exact-match parameter as well, to minimise the number of pages that have to be queried.

Hello, having the same problem, will there be a fix for this issue ?

The URI template in question came from #708. If you downgrade to 803.vd9c5e84c41fa_, then that version should not have this bug, but it has JENKINS-71355 instead.