jenkinsci / jenkinsci/gerrit-trigger-plugin

[JENKINS-38046] Gerrit Trigger Plugin Should be a Source for Multibranch Pipeline

Open
#800 26 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

component:gerrit-trigger-plugin enhancement imported-jira-issue pipeline priority:major resolution:unresolved
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
2 attachments

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.