Make Jenkins Pipelines Templates more Flexible

Is your feature request related to a problem?

In the CodeAbility project we have many instructors that propose specific requirements on Test executions. Currently the Jenkins pipeline definition template in src/main/resources/templates/jenkins/…/JenkinsFile is very unflexible. It only allows replacement of certain dedicated variables.

However we need more flexible ways to define pipelines, e.g. if-then-else based on exercise variables.

E.g. in freemarker markup

pipeline {
        options {
            timeout(time: <#if exercise.difficulty=EASY>${jenkinsTimeout}<#else>${5*jenkinsTimeout}</#if>
        }
...
steps {
<#if exercise.categories.contain('requiresUI')>
            wrap([$class: 'Xvnc', takeScreenshot: false, useXauthority: true]) {
</#if>
                junit ...
<#if exercise.categories.contain('requiresUI')>
        }
</#if>
        }

Describe the solution you’d like

1. We would propose to replace the current static textual variable replacements by more flexible ways of a template generator (e.g. freemarker
2. Provide more flexible ways to provide (Jenkins) templates. I.e. do not freeze it in the source code, but e.g. load it from a configurable URL/Filesystem/… .

Describe alternatives you’ve considered

There are not really good alternatives:

• restrict our instructor users to the definitions available
• manually make changes in Jenkins pipelines

Additional context

We volunteer to provide a solution above.

The change can be done in a first implementation transparent to upgrades. The resulting files will be identical between old and new generation mechanisms. On the long run, we want to implement further exercise attributes to configure the pipeline configuration.

Also flexible template generation can be applied to other templates (e.g. example generation).

[Wallenstein61]

Hello, just as an intermediate feedback. I have played around with your proposal. Had a hard time to get it running (not being a groovy expert).

It seemed that there was a

   return this;

missing at the end of “pipeline.groovy”. ( see https://stackoverflow.com/questions/54838794/jenkinsfile-java-lang-nullpointerexception-cannot-invoke-method-printpn-on )

The next step will be, to make it run inside our projects.

[b-fein]

Closing this issue as there is now a more detailed issue (#5726) describing how the approach as proposed above could be implemented as part of a proper integration into Artemis.