0

I know this is about outdated software but please bear with me. We're using the last version of the Jenkins v1.x branch. Having just migrated from Subversion to git, we need to reconfigure our CI to use git. One job needs to checkout two projects and build both to run the tests. Since the git plugin does not allow to check out different projects into different directories (see JENKINS-4535 and the various follow-ups - TLDR: it wasn't implemented), we're using the Multiple SCM plugin to achieve that.

Now we're being bitten by the fact that SCM polling does not work correctly in this setup and Jenkins runs the job every time even if there are no changes. I found this fix for when you're checking out two different branches of the same project, but in our case, we're checking out the same branch of different projects. I guess this is why the mentioned fix won't work, since the branch specifier is exactly the same for both of the projects.

Is there anything we can try to make this setup run correctly? Please note that there's a lot of transition work to do since the migration to git and thus upgrading Jenkins to v2.x or using pipelines - although definitely intended - is something that we'd really like to avoid right now.

zb226
  • 9,586
  • 6
  • 49
  • 79

2 Answers2

1

Try to separate pollling from checkout: you could define two additional "trigger" jobs, each polling one of your projects individually. Upon a change, each of those would trigger your main job (which then performs the actual checkout via Muliple SCM plugin).

Alex O
  • 7,746
  • 2
  • 25
  • 38
  • Thanks for your input, this is very likely a way to do it. However, we're now already in the process of updating to Jenkins 2.x and using the pipeline DSL. I'll post a minimal script for such a migration later on. – zb226 May 02 '17 at 08:14
0

We decided to update Jenkins to 2.x and use the declarative pipeline DSL, as our setup seemed impossible to migrate with an identical set of jobs (However Alex O's solution is a neat idea using additional trigger jobs) and it just seems like the right way to stay up-to-date with Jenkins.

Here's a skeleton of the script we've come up with. We could not get declarative SCM polling (triggers/pollSCM) to work - it just never triggered (but we're not alone on this one). Setting up a "classical" SCM trigger via the editor works, though. Kind of awkward, but OK for now.

pipeline {
    agent any
    stages {
        stage('checkout') {
            steps {
                checkout([
                    $class: 'GitSCM', branches: [[name: '*/master']], 
                    doGenerateSubmoduleConfigurations: false, 
                    extensions: [[
                        $class: 'RelativeTargetDirectory', 
                        relativeTargetDir: 'project1']], 
                    submoduleCfg: [], 
                    userRemoteConfigs: [[ credentialsId: '...', url: '...']]
                ])
                checkout([
                    $class: 'GitSCM', branches: [[name: '*/master']], 
                    doGenerateSubmoduleConfigurations: false, 
                    extensions: [[
                        $class: 'RelativeTargetDirectory', 
                        relativeTargetDir: 'project2']], 
                    submoduleCfg: [], 
                    userRemoteConfigs: [[ credentialsId: '...', url: '...']]
                ])
            }
        }
        stage('build') { steps { sh '...' } }
        stage('test') { steps { sh '...' } }
    }
}
Community
  • 1
  • 1
zb226
  • 9,586
  • 6
  • 49
  • 79