From version < 28.1 >
edited by Vincent Massol
on 2019/04/02 15:46
To version < 29.1 >
edited by Vincent Massol
on 2019/06/06 15:22
< >
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -31,6 +31,7 @@
31 31  * [[Attach the screenshot>>http://massol.myxwiki.org/xwiki/bin/view/Blog/AttachFailingTestPipeline]] of a failing XWiki Selenium test to the failed test's description
32 32  * Check for false positives for known cases of failures not related to code + [[check for test flickers>>http://massol.myxwiki.org/xwiki/bin/view/Blog/FlakyTestTool]]
33 33  * Send mails for build failures
34 +* Supports passing custom job properties. See below for an example of how to use this to trigger nightly build of Docker-based configuration tests.
34 34  
35 35  Note that if you use a "Github Organization" job type in Jenkins you'll get branch management for free, i.e. automatically build branches when new branches are added (or Pull Requests), and automatically stop building branches when they are removed from the SCM.
36 36  
... ... @@ -71,6 +71,80 @@
71 71  * {{scm project="xwiki-commons" path="Jenkinsfile"}}xwiki-commons's Jenkinsfile{{/scm}}
72 72  * {{scm project="xwiki-platform" path="Jenkinsfile"}}xwiki-platform's Jenkinsfile{{/scm}}
73 73  
75 +=== Nightly Configuration Tests ===
76 +
77 +Heres an example of how you can setup your ##Jenkinsfile## to automatically have execution of Docker-based configuration tests every night. This example is taken from {{scm project="xwiki-platform" path="Jenkinsfile"}}xwiki-platform's Jenkinsfile{{/scm}}.
78 +
79 +* Step 1: In the ##xwikiBuild## step, pass the ##jobProperties## configuration with some scheduler cron. For example:(((
80 +{{code language="groovy"}}
81 +xwikiBuild(map.name) {
82 + ...
83 + jobProperties = getCustomJobProperties()
84 + ...
85 +}
86 +
87 +private def getCustomJobProperties()
88 +{
89 + // Define a scheduler job to execute the Docker-based functional tests at regular intervals. We do this since they
90 + // take time to execute and thus we cannot run them all the time.
91 + // This scheduler job will pass the "type" parameter to this Jenkinsfile when it executes, allowing us to decide if
92 + // we run the standard builds or the docker ones.
93 + // Note: it's the xwikiBuild() calls from the standard builds that will set the jobProperties and thus set up the
94 + // job parameter + the crons. It would be better to set the properties directly in this Jenkinsfile but we haven't
95 + // found a way to merge properties and calling the properties() step will override any pre-existing properties.
96 + return [
97 + parameters([string(defaultValue: 'standard', description: 'Job type', name: 'type')]),
98 + pipelineTriggers([
99 + parameterizedCron('''@midnight %type=docker-latest
100 [email protected] %type=docker-all
101 [email protected] %type=docker-unsupported'''),
102 + cron("@monthly")
103 + ])
104 + ]
105 +}
106 +{{/code}}
107 +)))
108 +* Step 2: Based on the parametrized ##type## value, decide to execute Docker-based tests:(((
109 +{{code language="groovy"}}
110 +...
111 +if (params.type && params.type == 'docker-latest') {
112 + buildDocker('docker-latest')
113 +}
114 +...
115 +private void buildDocker(type)
116 +{
117 + def dockerConfigurationList
118 + def dockerModuleList
119 + def customJobProperties
120 + node() {
121 + // Checkout platform to find all docker configurations and test modules so that we can then parallelize executions
122 + // of configs and modules across Jenkins agents.
123 + checkout skipChangeLog: true, scm: scm
124 + dockerConfigurationList = dockerConfigurations(type)
125 + if (type == 'docker-unsupported') {
126 + dockerModuleList = ['xwiki-platform-core/xwiki-platform-menu']
127 + } else {
128 + dockerModuleList = dockerModules()
129 + }
130 + customJobProperties = getCustomJobProperties()
131 + }
132 +
133 + xwikiDockerBuild {
134 + configurations = dockerConfigurationList
135 + modules = dockerModuleList
136 + // Make sure that we don't reset the job properties!
137 + jobProperties = customJobProperties
138 + }
139 +}
140 +{{/code}}
141 +)))
142 +
143 +Pros/Cons of this approach (which is needed because Jenkins doesn't support more than one ##Jenkinsfile##) vs using a separate job:
144 +* Pros:
145 +** No need to handle branches, done automatically by the ##Jenkinsfile## (creation and deletion). Also works for PRs.
146 +* Cons:
147 +** Jenkins build history gets a bit messed up (but test history is kept).
148 +
74 74  == Clover Pipeline ==
75 75  
76 76  Used to generate the global test coverage for XWiki (over all XWiki Standard repositories). See [[Test Coverage>>Community.Testing.TestCoverage.WebHome]].
... ... @@ -87,35 +87,6 @@
87 87  }
88 88  {{/code}}
89 89  
90 -== Docker Pipeline ==
91 -
92 -Used to run functional tests using Docker in various supported configurations. See the [[defined Jobs>>Community.Testing.DockerTesting.WebHome#HCIJobs]].
93 -
94 -Example usage:
95 -
96 -{{code language="groovy"}}
97 -import org.xwiki.jenkins.DockerTests
98 -
99 -def branchNames = ['master', 'stable-10.11.x']
100 -def branches = [:]
101 -
102 -branchNames.each() {
103 - branches[it] = {
104 - def label
105 - if (it.contains('10.11.x')) {
106 - label = 'docker-outside-docker'
107 - } else {
108 - label = 'docker'
109 - }
110 - node(label) {
111 - new DockerTests().executeDockerSupportedTests(it)
112 - }
113 - }
114 -}
115 -
116 -parallel branches
117 -{{/code}}
118 -
119 119  = Maintainer's guide =
120 120  
121 121  == Prerequisites ==

General

XWiki has a Continuous Integration setup to ensure XWiki's code is built at all times (i.e at every code check in). This also allows developers to only build the module they want and they'll have the other XWiki module dependencies downloaded from the XWiki remote repository.

We use the following tools:

We use a technique called binary dependency build which allows to check out only the module a developer wishes to work on and he'll automatically get the latest fresh binary dependencies built by our CI tool.

Jenkins Agent Image

XWiki has its own Jenkins Agent Docker image that is used by Jenkins master to spawn agents.

Jenkins Pipelines

Main Pipeline

We have developed a Jenkins Pipeline script to build XWiki projects (can be used for core and contrib projects). It has the following features:

  • Automatically use the right version of Java (and proper memory configuration)
  • Use Jenkins's Xvnc plugin to have a Display for functional tests
  • Use the "deploy" maven goal for "master" and "stable-*" branches only and "install" for the rest
  • Attach the screenshot of a failing XWiki Selenium test to the failed test's description
  • Check for false positives for known cases of failures not related to code + check for test flickers
  • Send mails for build failures
  • Supports passing custom job properties. See below for an example of how to use this to trigger nightly build of Docker-based configuration tests.

Note that if you use a "Github Organization" job type in Jenkins you'll get branch management for free, i.e. automatically build branches when new branches are added (or Pull Requests), and automatically stop building branches when they are removed from the SCM.

To use is for a project, add a Jenkinsfile with the following minimal configuration:

/*
 * See the NOTICE file distributed with this work for additional
 * information regarding copyright ownership.
 *
 * This is free software; you can redistribute it and/or modify it
 * under the terms of the GNU Lesser General Public License as
 * published by the Free Software Foundation; either version 2.1 of
 * the License, or (at your option) any later version.
 *
 * This software is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this software; if not, write to the Free
 * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
 */


// It's assumed that Jenkins has been configured to implicitly load the vars/xwikiModule.groovy library which exposes
// the "xwikiModule" global function/DSL.
// Note that the version used is the one defined in Jenkins but it can be overridden as follows:
// @Library("[email protected]") _
// See https://github.com/jenkinsci/workflow-cps-global-lib-plugin for details.

xwikiModule {
}

For more elaborate configuration, see:

Nightly Configuration Tests

Heres an example of how you can setup your Jenkinsfile to automatically have execution of Docker-based configuration tests every night. This example is taken from xwiki-platform's Jenkinsfile.

  • Step 1: In the xwikiBuild step, pass the jobProperties configuration with some scheduler cron. For example:
    xwikiBuild(map.name) {
     ...
      jobProperties = getCustomJobProperties()
     ...
    }

    private def getCustomJobProperties()
    {
     // Define a scheduler job to execute the Docker-based functional tests at regular intervals. We do this since they
     // take time to execute and thus we cannot run them all the time.
     // This scheduler job will pass the "type" parameter to this Jenkinsfile when it executes, allowing us to decide if
     // we run the standard builds or the docker ones.
     // Note: it's the xwikiBuild() calls from the standard builds that will set the jobProperties and thus set up the
     // job parameter + the crons. It would be better to set the properties directly in this Jenkinsfile but we haven't
     // found a way to merge properties and calling the properties() step will override any pre-existing properties.
     return [
        parameters([string(defaultValue: 'standard', description: 'Job type', name: 'type')]),
        pipelineTriggers([
          parameterizedCron('''@midnight %type=docker-latest
    @weekly %type=docker-all
    @monthly %type=docker-unsupported'''
    ),
          cron("@monthly")
       ])
     ]
    }
  • Step 2: Based on the parametrized type value, decide to execute Docker-based tests:
    ...
    if (params.type && params.type == 'docker-latest') {
      buildDocker('docker-latest')
    }
    ...
    private void buildDocker(type)
    {
     def dockerConfigurationList
     def dockerModuleList
     def customJobProperties
     node() {
       // Checkout platform to find all docker configurations and test modules so that we can then parallelize executions
       // of configs and modules across Jenkins agents.
       checkout skipChangeLog: true, scm: scm
        dockerConfigurationList = dockerConfigurations(type)
       if (type == 'docker-unsupported') {
          dockerModuleList = ['xwiki-platform-core/xwiki-platform-menu']
       } else {
          dockerModuleList = dockerModules()
       }
        customJobProperties = getCustomJobProperties()
     }

      xwikiDockerBuild {
        configurations = dockerConfigurationList
        modules = dockerModuleList
       // Make sure that we don't reset the job properties!
       jobProperties = customJobProperties
     }
    }

Pros/Cons of this approach (which is needed because Jenkins doesn't support more than one Jenkinsfile) vs using a separate job:

  • Pros:
    • No need to handle branches, done automatically by the Jenkinsfile (creation and deletion). Also works for PRs.
  • Cons:
    • Jenkins build history gets a bit messed up (but test history is kept).

Clover Pipeline

Used to generate the global test coverage for XWiki (over all XWiki Standard repositories). See Test Coverage.

Example usage:

import org.xwiki.jenkins.Clover
node('docker') {
   new Clover().generateGlobalCoverage([
       [baseline: "20171222-1835", fail: false],
       [baseline: "20190101-2330", fail: true]
   ])
}

Docker Pipeline

Used to run functional tests using Docker in various supported configurations. See the defined Jobs.

Example usage:

import org.xwiki.jenkins.DockerTests

def branchNames = ['master', 'stable-10.11.x']
def branches = [:]

branchNames.each() {
  branches[it] = {
   def label
   if (it.contains('10.11.x')) {
      label = 'docker-outside-docker'
   } else {
      label = 'docker'
   }
    node(label) {
     new DockerTests().executeDockerSupportedTests(it)
   }
 }
}

parallel branches

Maintainer's guide

Prerequisites

  • You need to have an account on maven.xwiki.org (this is the machine hosting XWiki's remote repository) and you'll need a key setup on your account there so that you can ssh to it without having to enter username or password.
  • You need to have an administrator account on ci.xwiki.org.

Functional tests

Debugging

Connect to the XVNC server

  • Establish a SSH tunnel between your computer and the server on port 5901 (ssh -L 5901:localhost:5901 )
  • Use your favorite VNC client to connect to the XVNC server
    • Host : localhost
    • Display : 1
    • Password : same password as for XWiki SAS wifi access points
  • See the functional tests live.
  • Work in progress to try to connect to an agent not exposing an IP address externally (by going through maven.xwiki.org):
    • ssh -L 5901:192.168.1.119:5901 -o ProxyCommand="ssh [email protected] nc -w1 %h %p" hudsonagent@192.168.1.119 -i ~/.ssh/id_rsa_mavenxwikiorg
    • Where /.ssh/id_rsa_mavenxwikiorg is the private key on maven.xwiki.org, used to connect to 192.168.1.119 (ip of agent 2-4 in this example)
    • Not working yet since I can't connect with my local vnc client.

Get Connected