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

273 views
Skip to first unread message

kasberg.mike@gmail.com (JIRA)

unread,
Sep 7, 2016, 7:39:04 PM9/7/16
to jenkinsc...@googlegroups.com
Mike Kasberg created an issue
 
Jenkins / Improvement JENKINS-38046
Gerrit Trigger Plugin Should be a Source for Multibranch Pipeline
Issue Type: Improvement Improvement
Assignee: rsandell
Components: gerrit-trigger-plugin
Created: 2016/Sep/07 11:38 PM
Environment: Jenkins 2.7.3, Gerrit Trigger Plugin 2.22.0
Labels: pipeline
Priority: Major Major
Reporter: Mike Kasberg

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.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

kasberg.mike@gmail.com (JIRA)

unread,
Sep 8, 2016, 6:35:02 PM9/8/16
to jenkinsc...@googlegroups.com
Mike Kasberg commented on Improvement JENKINS-38046
 
Re: Gerrit Trigger Plugin Should be a Source for Multibranch Pipeline

Here is an (ugly) workaround:

Use a normal pipeline job with the gerrit trigger. Have the pipeline execute a simple bootstrapping script, which loads the correct Jenkinsfile. The script might look like this:

{{
#!/usr/bin/env groovy

node('label') {
stage 'Checkout' {
// Checkout the patch set we're testing.
// See https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger#GerritTrigger-PipelineJobs
// Using Gerrit Trigger with Pipeline jobs.

git url: 'ssh://foo@gerrit/repository'
def changeBranch = "change-$

{GERRIT_CHANGE_NUMBER}

-$

{GERRIT_PATCHSET_NUMBER}

"
sh "git fetch origin $

{GERRIT_REFSPEC}

:$

{changeBranch}"
sh "git checkout ${changeBranch}

"
sh "git clean -d -f -q -x"
}

// The rest comes from the repository itself!
load 'Jenkinsfile'
}
}}

kasberg.mike@gmail.com (JIRA)

unread,
Sep 8, 2016, 6:36:01 PM9/8/16
to jenkinsc...@googlegroups.com
Mike Kasberg edited a comment on Improvement JENKINS-38046
Here is an (ugly) workaround:

Use a normal pipeline job with the gerrit trigger. Have the pipeline execute a simple bootstrapping script, which loads the correct Jenkinsfile. The script might look like this:

{ { code}
#!/usr/bin/env groovy

node('label') {
    stage 'Checkout' {
        // Checkout the patch set we're testing.
        // See https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger#GerritTrigger-PipelineJobs
        // Using Gerrit Trigger with Pipeline jobs.

        git url: 'ssh://foo@gerrit/repository'
            def changeBranch = "change-${GERRIT_CHANGE_NUMBER}-${GERRIT_PATCHSET_NUMBER}"
            sh "git fetch origin ${GERRIT_REFSPEC}:${changeBranch}"
            sh "git checkout ${changeBranch}"
            sh "git clean -d -f -q -x"
    }

    // The rest comes from the repository itself!
    load 'Jenkinsfile'
}
{code } }

stephen.alan.connolly@gmail.com (JIRA)

unread,
Feb 24, 2017, 10:35:06 AM2/24/17
to jenkinsc...@googlegroups.com

austin.phillips@planetinnovation.com.au (JIRA)

unread,
Mar 6, 2017, 9:34:03 PM3/6/17
to jenkinsc...@googlegroups.com
Austin Phillips commented on Improvement JENKINS-38046
 
Re: Gerrit Trigger Plugin Should be a Source for Multibranch Pipeline

Here's another workaround using a normal pipeline job with the gerrit trigger plugin.

  • Set up Gerrit triggers as per normal
  • Set up Pipeline with 'Pipeline script from SCM', using the Gerrit environment variables as source information for the Jenkinsfile
  • Use a Jenkinsfile in your source as normal, complete with 'checkout scm' step.

Configuration of the Pipeline SCM is as follows:

  • Set 'Repository URL' to $GERRIT_SCHEME://$GERRIT_HOST:$GERRIT_PORT/$GERRIT_PROJECT
  • Click the 'Advanced' button and set 'Refspec' to $GERRIT_REFSPEC:$GERRIT_REFSPEC
  • Set 'Branches to build' to $GERRIT_REFSPEC
  • If desired, add 'Advanced clone behaviours' with 'Shallow clone' enabled with a 'Shallow clone depth' set to 1.

Then, in your Gerrit repository Jenkins file:

 

 node {
    stage('Checkout') {
        checkout scm
   }
   stage('Build') {
       echo "Building...'
   }
}

 

Additional information:

  • The advantage of this method is that there is only a single Jenkinsfile specification which lives in your SCM.
  • The Pipeline configuration can be consistent across multiple projects as all of the SCM information is derived from Gerrit Trigger environment variables.  The Gerrit Trigger parameters become the source for the Jenkinsfile pipeline definition.
  • The Jenkins master will check out a copy of the repository on the master to get access to the Jenkinsfile (ie Not in a workspace)
  • The 'checkout scm' step inside the pipeline will check out the code according to the SCM information entered in the pipeline step.  Because the checkout occurs inside a 'node' block, the source repo ends up being checked out twice.  Once to obtain the Jenkinsfile by the master, once as part of the Jenkinsfile pipeline step.  The shallow clone options may help speed things up here.
  • This has only been tested with the 'Patchset Created' Gerrit Trigger type.

 

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

austin.phillips@planetinnovation.com.au (JIRA)

unread,
Mar 6, 2017, 10:43:03 PM3/6/17
to jenkinsc...@googlegroups.com
Austin Phillips edited a comment on Improvement JENKINS-38046
Here's another workaround using a normal pipeline job with the gerrit trigger plugin.
* Set up Gerrit triggers as per normal
* Set up Pipeline with 'Pipeline script from SCM', using the Gerrit environment variables as source information for the Jenkinsfile
* Use a Jenkinsfile in your source as normal, complete with 'checkout scm' step.


Configuration of the Pipeline SCM is as follows:
* Set 'Repository URL' to {{$GERRIT_SCHEME://$GERRIT_HOST:$GERRIT_PORT/$GERRIT_PROJECT}}
* Click the 'Advanced' button and set 'Refspec' to {{$GERRIT_REFSPEC:$GERRIT_REFSPEC}}
* Set 'Branches to build' to {{$GERRIT_REFSPEC}}
* If desired, add 'Advanced clone behaviours' with 'Shallow clone' enabled with a 'Shallow clone depth' set to 1.
* Untick 'Lightweight checkout'

Then, in your Gerrit repository Jenkins file:

 
{noformat}

 node {
    stage('Checkout') {
        checkout scm
   }
   stage('Build') {
       echo "Building...'
   }
}{noformat}
 

Additional information:
* The advantage of this method is that there is only a single Jenkinsfile specification which lives in your SCM.
* The Pipeline configuration can be consistent across multiple projects as all of the SCM information is derived from Gerrit Trigger environment variables.  The Gerrit Trigger parameters become the source for the Jenkinsfile pipeline definition.
* The Jenkins master will check out a copy of the repository on the master to get access to the Jenkinsfile (ie Not in a workspace)
* The 'checkout scm' step inside the pipeline will check out the code according to the SCM information entered in the pipeline step.  Because the checkout occurs inside a 'node' block, the source repo ends up being checked out twice.  Once to obtain the Jenkinsfile by the master, once as part of the Jenkinsfile pipeline step.  The shallow clone options may help speed things up here.
* This has only been tested with the 'Patchset Created' Gerrit Trigger type.
* The 'Lightweight checkout' options appears not to work due to the way that git is used for this option. Following error is generated: 
hudson.plugins.git.GitException: Command "git fetch --tags --progress origin +refs/heads/$GERRIT_REFSPEC:refs/remotes/origin/$GERRIT_REFSPEC --prune" returned status code 128:

 

lucamilanesio@java.net (JIRA)

unread,
Apr 6, 2018, 12:00:06 PM4/6/18
to jenkinsc...@googlegroups.com

Jesse Glick the new plugin has now been renamed to ([Gerrit Code Review plugin](https://github.com/jenkinsci/gerrit-code-review-plugin) and is now available for installation through the Jenkins Plugin Manager.

taylorp36@gmail.com (JIRA)

unread,
Apr 10, 2018, 8:00:02 PM4/10/18
to jenkinsc...@googlegroups.com

Will this capability be added to gerrit-trigger-plugin? I am weary of installing another gerrit plugin and having 2 ways of configuring pipelines (multi-branch and regular).

josesa@java.net (JIRA)

unread,
Aug 14, 2018, 2:01:03 PM8/14/18
to jenkinsc...@googlegroups.com
Jose Sa commented on Improvement JENKINS-38046

I'm using this trigger in multi-branch but seems to be ignored:

  triggers {
    gerrit(
      serverName: 'server-name',
      gerritProjects: [[
        compareType: 'PLAIN',
        pattern: '_REPO_',
        branches: [[ compareType: 'ANT', pattern: 'refs/heads/*' ]],
        filePaths: [[ compareType: 'ANT', pattern: "_MODULE_/**" ]],
        disableStrictForbiddenFileVerification: false
      ]],
      triggerOnEvents: [
        refUpdated()
      ]
    )
  }

The only thing that makes build happen is the polling scheduled every 5 minutes (as workaround) checking for branch changes.

Should I use something differently to get multibranch jobs triggered ?

This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

jenkins-ci@munkyboy.com (JIRA)

unread,
Aug 28, 2019, 6:16:04 PM8/28/19
to jenkinsc...@googlegroups.com
Mike commented on Improvement JENKINS-38046

Austin Phillips
thanks for your solution! It's not multi-branch but it is working well for me.

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
Reply all
Reply to author
Forward
0 new messages