I anyone else interesting in making this happen? Currently we can configure the multibranch-job to get branches from gerrit by using the git as the source branch but this is limited to normal branches, not change-requests.
Doing this for change requests is impossible via git only because while Gerrit exposes all of them, it does in a way that makes them unusable for CI
- the is no single branch per review, easy change being visible as another branch.
- the abandoned or merged reviews are not removed from list of branches, so they only grow
- most Gerrit servers to have rate limiters for "git ls-remote".
So, what we need is to use Gerrit API in order to retrieve the current list or reviews that are supposed to be build and to map them to a single review branch. Initially I was considering to make each review visible as a temporary branch but I am starting to believe that this approach does not scale well, cluttering the user interface. My impression is that it could be better if we create a single review(pr) branch for each target branch, or even just a single one.
Can we at least get some architecture guidance from someone that knows involved Jenkins plugins and API better? It would very useful to get a bill-of-materials that would look like: fork or clone this plugin and modify these classes, ...
I digged a little bit last night and observed that branch detection is happening inside git-client-plugin, but I also know that there are two plugins that, based on their names, are supposed to provide exactly the same kind of feature but for other services: github-branch-source-plugin, bitbucket-branch-source-plugin and even an unmaintained proof of concept gitlab-branch-source-plugin. Both of them are quite complex in nature and I don't know if we should clone on of them and start to rewrite it to make it work with Gerrit. Or the solution is to add this functionality to the gerrit-trigger-plugin?
Either way, I could use some guidance: what is the minimum change needed and where it should be implemented?