JENKINS-36780 Pipeline support

[drekbour]

Complete rework of #3. This adds the technical ability to apply templating to pipeline jobs (WorkflowJob) with a distinct set exclusions from the the classic project (AbstractProject) mode.

It does not answer much about the impact of doing this so will sit as a WIP even if integrated into master until we're a bit more certain of the end-to-end flow.

[drekbour]

As an example, a pipeline with parameters as below will set ParametersDefinitionProperty each time it is run (note run not saved)

pipeline {
    agent any

    parameters {
        booleanParam(defaultValue: true, description: '', name: 'userFlag')
    }

    stages {
        stage("foo") {
            steps {
                echo "flag: ${params.userFlag}"
            }
        }
    }
}

<hudson.model.ParametersDefinitionProperty>
      <parameterDefinitions>
        <hudson.model.BooleanParameterDefinition>
          <name>userFlag</name>
          <description></description>
          <defaultValue>true</defaultValue>
        </hudson.model.BooleanParameterDefinition>

The interaction with EZT merging ParametersDefinitionProperty on save with pipeline doing so on run is a bit weird. It's further complicated by the distinction of inline script (held as a JobProperty) or a committed Jenkinsfile. Frankly - I think ETZ cannot work safely with a Jenkinsfile

[drekbour]

@juanpablo-santos @jxramos You had opinions on this previously, can you tell me a little about how you think this 'works'

[juanpablo-santos]

Hi @drekbour,

apologies for the late response, Christmas caught up with me :-) Haven't been able to look at the code yet but, said that, pipelines from templated jobs shouldn't define parameters themselves, but use those defined at the job level: parameters defined at pipeline level cannot be templated, whereas those defined at job level can, being that the main use for EZT for pipeline jobs.

None of our pipelines defines parameters, so we haven't come across the ParametersDefinitionProperty being set on each job run. In any case, I agree, it is weird, the plugin should be able to detect an omit those cases.

EZT should somehow omit doing anything if the parameter is defined on a pipeline (the parameter wouldn't be "templatable"), and that would also fix the issue with the plugin doing something on pipeline runs. More precisely, it would be ok for me if the plugin ends up triggered by pipeline runs (because of Jenkins internals or whatever), but the plugin is able to detect this situation, or that the property comes from a pipeline, and do nothing.

Allow me a couple of weeks to take a look at this, and I'll update with whatever I come up with.

br,
juan pablo