Jenkins Pipeline emailext $class parameter for recipientProviders

Question

I have been trying to get my head around the pipeline groovy code below:

emailext (
        subject: "STARTED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]'",
        body: """<p>STARTED: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]':</p>
          <p>Check console output at &QUOT;<a href='${env.BUILD_URL}'>${env.JOB_NAME} [${env.BUILD_NUMBER}]</a>&QUOT;</p>""",
        recipientProviders: [[$class: 'DevelopersRecipientProvider']]
      )

1) Does the dollar sign before the class (which is $class) have some special meaning? I know it refers to the class type DevelopersRecipientProvider but is $class some sort of special reserved word in groovy to indicate class type?

2) In the source code, recipientProviders is a List but what exactly is being assigned to it in the code above? Is it a list of maps?

3) Where is emailext defined in the email ext plugin source code? I searched for emailext in all the .groovy files in the plugin source code but can't seem to find something that looks like the emailext call above.

I would appreciate if someone could shed some light on the above, thanks.

Answer 1

To add, the $class literal is a special key used by the Jenkins Pipeline. When editing a pipeline job, set the script source to inline (not SCM) and there is a link to the syntax reference. In that section there is a sub-section "Steps Reference" which is at https://<jenkins url>/job/<job name>/pipeline-syntax/html.

As maps of parameters. Default values may be omitted. (Note that [1, 2, 3] is a list in Groovy whereas [a: 1, b: 2, c: 3] is a map.)

The special map key $class is used to represent the simple or (where necessary) fully-qualified class name of the object being requested. $class may be omitted where the containing parameter allows only a single kind of nested object (or list of them):

checkout([$class: 'GitSCM', userRemoteConfigs: [[url: 'git://…'], extensions: [[$class: 'CleanBeforeCheckout']]])

In this example, GitSCM must be specified to distinguish the kind of SCM used by the delegate of checkout (the single mandatory parameter name delegate can be omitted), and CleanBeforeCheckout must be specified to distinguish the kind of GitSCMExtension used by the extensions of GitSCM — a “heterogeneous” list; but $class: 'UserRemoteConfig' may be omitted since the userRemoteConfigs of GitSCM are defined to contain only UserRemoteConfigs — it is a “homogeneous” list. (No such omission is permitted for homogeneous lists in the first syntax.)

Note that in cases where a single parameter is given, with the name omitted, and that parameter is a map, it must be enclosed in parentheses to avoid a syntactic ambiguity.