Page MenuHomeDevCentral

Create a new Jenkins template for PHP applications
Open, NormalPublic

Description

For the notifications center development (rNOTIF), we were happy with a Jenkins PHP template prepared by Sebastian Bergmann (phpunit), http://jenkins-php.org/, not maintained anymore.

The main feature we used were the phpunit tests, phpcs and the code coverage.

A lot of those components aren't maintained anymore at Jenkins level and marked as deprecated. A lot of them are now a part of the Jenkins Warnings Plugin:

"The Jenkins Next Generation Warnings plug-in replaces the whole Jenkins Static Analysis Suite. I.e. it makes the following Jenkins plugins obsolete: Android Lint, CheckStyle, Dry, FindBugs, PMD, Warnings, Static Analysis Utilities, Static Analysis Collector."

Meanwhile:

  • some tools we use and consider important, like phan, aren't called in CI -> let's add them
  • a declarative pipeline syntax exist

A new PHP template would so be helpful.

The expected format is a modern Jenkinsfile pipeline.

Plugins used in legacy template

PluginRoleStatusAlternative plan
Checkstyleprocessing PHP_CodeSniffer logfiles in Checkstyle formatdeprecatedphpcs can be run without dedicated plugin, but it's also now a part of the Jenkins Warnings Plugin
Clover PHPprocessing PHPUnit's Clover XML logfileOKkeep it to offer a test coverage dashboard
Crap4Jprocessing PHPUnit's Crap4J XML logfileOK?
DRYprocessing phpcpd logfiles in PMD-CPD formatdeprecatedNow a part of the Jenkins Warnings Plugin
HTML Publisherpublishing documentation generated by phpDox, for instanceOKnot needed
JDependprocessing PHP_Depend logfiles in JDepend formatOK?
Plotprocessing phploc CSV outputOK?
PMDprocessing PHPMD logfiles in PMD formatdeprecatedNow a part of the Jenkins Warnings Plugin
Violationsprocessing various logfilesdeprecatedcan be implemented by the Jenkins Warnings Plugin
Warningsprocessing PHP compiler warnings in the console logdeprecatedSuperseded by the Jenkins Warnings Plugin
xUnitprocessing PHPUnit's JUnit XML logfileOKKeep, and migrate to pipelines

Example of how to use the warnings plugin

There is an integrated mode where we can run through Maven a script pretty similar to the current XML we use to define jobs, collect results with scanForIssues and then publish them with publishIssues:

Jenkinsfile
node {
    ...

    stage('Analysis') {
        def mvnHome = tool 'mvn-default'

        sh "${mvnHome}/bin/mvn --batch-mode -V -U -e checkstyle:checkstyle pmd:pmd pmd:cpd"
        def checkstyle = scanForIssues tool: checkStyle(pattern: '**/target/checkstyle-result.xml')
        publishIssues issues: [checkstyle]
   
        def pmd = scanForIssues tool: pmdParser(pattern: '**/target/pmd.xml')
        publishIssues issues: [pmd]
        
        def cpd = scanForIssues tool: cpd(pattern: '**/target/cpd.xml')
        publishIssues issues: [cpd]

        def maven = scanForIssues tool: mavenConsole()
        publishIssues issues: [maven]

        publishIssues id: 'analysis', name: 'All Issues', 
            issues: [checkstyle, pmd], 
            filters: [includePackage('io.jenkins.plugins.analysis.*')]
    }

    ...
}

Example of how to use the xunit plugin

Declarative pipeline format:

Jenkinsfile
pipeline {
    agent any

    stages {
        stage('Test'){
            steps {
                sh "run_tests.bash"
            }
        }
    }

    post {
        always{
            xunit (
                thresholds: [ skipped(failureThreshold: '0'), failed(failureThreshold: '0') ],
                tools: [ BoostTest(pattern: 'boost/*.xml') ])
            )
        }
    }
 }

Example of how to use the HTML Publisher plugin

This plugin has some documented advanced syntax features.

Like we do for Rust, we can create a Documentation step with a sh call to phpDox, then something like:

publishHTML (target : [
  allowMissing: false,
  alwaysLinkToLastBuild: false,
  keepAll: true,
  reportDir: 'build/api',
  reportFiles: 'index.html',
  reportName: 'API Documentation',
  reportTitles: 'API doc'])

(values based on current config.xml content)

Keep or discard build.xml?

Currently a build.xml file is included in each PHP project, as an ant script to call the different tools. This format is a popular alternative of Makefile in Java world.

We can keep it and call it through:

  • sh "ant phabricator-build" for quick tests triggered by a new Phabricator revision in code review
  • sh "ant" (without any target specified), for default suite of tests, triggered by new commits in main branch

This script will run the tests, all the static analysis tools, the documentation, populate the result files.

And then we can call the warnings plugin (see above).

Or we can supersede it by pure Jenkinsfile, like here.

A middle ground approach could also be:

  • Keep build.xml for static analysis
  • Move non static analysis stuff in Jenkinsfile (e.g. documentation)

The moved content would then be the content belonging to other steps.

That would have the benefit to allow the analysis to run fully without failing and to get a comprehensive report of what happens. I'd especially like if phpcs fails, it still runs phan (phan to add by the way somewhere, in build.xml or Jenkinsfile).

Event Timeline

dereckson triaged this task as Normal priority.Oct 12 2020, 00:38
dereckson created this task.
dereckson updated the task description. (Show Details)
dereckson updated the task description. (Show Details)
dereckson updated the task description. (Show Details)
dereckson updated the task description. (Show Details)

First plan of action could be to ensure we've effectively and explicitly in the job configuration moved to Next Generation Warnings plugin.

Reference: https://plugins.jenkins.io/warnings-ng/