jenkinsci / jenkinsci/gerrit-trigger-plugin
[JENKINS-38046] Gerrit Trigger Plugin Should be a Source for Multibranch Pipeline
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 226
- Forks
- 289
- PR merge metrics
- No merged PRs in 30d
Description
I want to use the new Multibranch Pipeline features of Jenkins with Gerrit source control.
I should be able to choose Gerrit as the source for a multibranch pipeline. I should be able to select one or more repositories from Gerrit that each have their own Jenkinsfile. The pipeline would run the Jenkinsfile from the patch set that was pushed to Gerrit.
There is no known workaround for this issue because one core requirement is to see each gerrit branch and change request as a different sub-job with its own history. This is essential because it allow you to know the build status of the branch instead of seeing a long queue of builds made on various branches and CRs, most likely full of failures.
The behaviour described in this ticket is almost identical with the GitHub Multibranch implementation, the difference is that instead of having GitHub branches and PRs as the data source, we want to have Gerrit.
Originally reported by mkasberg, imported from: Gerrit Trigger Plugin Should be a Source for Multibranch Pipeline
- assignee: lucamilanesio
- status: In Progress
- priority: Major
- component(s): gerrit-trigger-plugin
- label(s): gerrit, multibranch, pipeline
- resolution: Unresolved
- votes: 48
- watchers: 57
- imported: 2025-12-06
Raw content of original issue
I want to use the new Multibranch Pipeline features of Jenkins with Gerrit source control.
I should be able to choose Gerrit as the source for a multibranch pipeline. I should be able to select one or more repositories from Gerrit that each have their own Jenkinsfile. The pipeline would run the Jenkinsfile from the patch set that was pushed to Gerrit.
There is no known workaround for this issue because one core requirement is to see each gerrit branch and change request as a different sub-job with its own history. This is essential because it allow you to know the build status of the branch instead of seeing a long queue of builds made on various branches and CRs, most likely full of failures.
The behaviour described in this ticket is almost identical with the GitHub Multibranch implementation, the difference is that instead of having GitHub branches and PRs as the data source, we want to have Gerrit.
- environment:
Jenkins 2.7.3, Gerrit Trigger Plugin 2.22.0
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no source files or tests. Start by comparing the existing GitHub Multibranch implementation with the gerrit-trigger-plugin integration points, then define how Gerrit repositories, branches, and change requests map to separate sub-jobs and how each patch set supplies its Jenkinsfile. Done means Gerrit can be selected as a multibranch source with per-branch and per-change history.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- ci-cd, devops
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100

