2.0 pipeline steps for beats

[v1v]

What does this PR do?

Specific steps for the beats 2.0 pipeline:

• beatsWhen
• beatsStages

That consume a YAML data structure such as:

when:
    branches: true             ## for all the branches
    changeset:                 ## when PR contains any of those entries in the changeset
        - "auditbeat"
        - "#metricbeat/beater" ## special token regarding the project dependency
        - '@ci'                ## special token regarding the changeset for the ci 
        - '@oss'               ## special token regarding the changeset for the oss 
    comments:                  ## when PR comment contains any of those entries
        - "/test auditbeat"
    labels:                    ## when PR labels matche any of those entries
        - "auditbeat"
    parameters:                ## when parameter was selected in the UI.
        - "auditbeat"
    tags: true                 ## for all the tags
    disabled: false
platform: "linux && ubuntu-16" ## default label for all the stages
stages:
    build:
        mage:
            - "mage build test"
    windows:
        mage:
            - "mage build unitTest"
        platforms:             ## override default labels in this specific stage.
            - "windows-2019"
            - "windows-2016"
        when:
            comments:
                - "/test auditbeat for windows"
            parameters:
                - "windows"
            disabled: true

## Changeset macros that are defined here and used in each specific 2.0 pipeline.
changeset:
    ci:
        - "^Jenkinsfile"
        - "^\\.ci/scripts/.*"
    oss:
        - "^go.mod"
        - "^libbeat/.*"
        - "^dev-tools/.*"
        - "^testing/.*"
    xpack:
        - "^go.mod"
        - "^libbeat/.*"
        - "^dev-tools/.*"
        - "^testing/.*"
        - "^x-pack/libbeat/.*" 

• Prepare a mardown with the reason of the build to happen

Why is it important?

Simplify and reuse steps with some UT/ITs

Related issues

Caused elastic/beats#20104

Test

• Markdown build reasons

• beatsWhen

• beatsStages

Tasks

• Changeset when implementation
• Set the closure with the right implementation to be used...
• Cast class warning
  • expected to call org.codehaus.groovy.runtime.MethodClosure.call but wound up catching WorkflowScript.runCommand; see: https://jenkins.io/redirect/pipeline-cps-method-mismatches/.
  • cb7b894 changed the paradigm to use a class instead calling a pointer to a function. elastic/beats@a3da232 is the implementation of the class.

[apmmachine]

💚 Build Succeeded

Expand to view the summary

Build stats

• Build Cause: [Pull request #689 updated]

• Start Time: 2020-09-14T10:57:52.314+0000

• Duration: 6 min 14 sec

Test stats 🧪

Test	Results
Failed	0
Passed	769
Skipped	18
Total	787

Steps errors

Expand to view the steps failures

• Name: Archive JUnit-formatted test results

  • Description: [2020-09-14T11:00:54.991Z] Recording test results
    [2020-09-14T11:00:55.437Z] Failed to read /var/li

  • Duration: 0 min 0 sec

  • Start Time: 2020-09-14T11:00:54.987+0000

  • log

[cachedout]

This looks like a very sensible and easy-to-understand approach. I like it. 💯

[cachedout]

I don't understand the need for this nested if conditional. It seems like both L33 and L36 are the same call?

[v1v]

If one of the stages contain a when condition then it's required to evaluate it before building the stages, for instance:

stages:
  stageA:
     make: foo
  stageB:
     make: bar
     when:
        labels:
           - 'foo'

There are two stages (stageA and stageB) but stageB will be enabled only if the GitHub labels match with foo. L32 is the one in charge of this evaluation.

[v1v]

Super-linter is broken, so this is unrelated to this PR