How to use email-ext plugin in pipeline script?

5,404 views
Skip to first unread message

David Aldrich

unread,
Apr 24, 2017, 12:02:53 PM4/24/17
to jenkins...@googlegroups.com

Hi

 

Here’s my pipeline:

 

1.  node('pc1') {

2.   

3.  stage('Checkout') {

4.      checkout([$class: 'SubversionSCM',

5.      additionalCredentials: [[credentialsId: '<snip>', realm: '']],

6.      excludedCommitMessages: '',

7.      excludedRegions: '',

8.      excludedRevprop: '',

9.      excludedUsers: '',

10.     filterChangelog: false,

11.     ignoreDirPropChanges: false,

12.     includedRegions: '',

13.     locations: [[credentialsId: '<snip>', depthOption: 'infinity', ignoreExternalsOption: false, local: '.', remote: '<snip>']],

14.     workspaceUpdater: [$class: 'UpdateUpdater']])

15. }  

16.  

17. sh '''make'''

18.  

19. emailext attachLog: true, body: '$DEFAULT_CONTENT', subject: '$DEFAULT_SUBJECT', to: '<snip>'

20.  

21. }

 

The resulting email has result ‘BUILDING’.  How should I change the script to make email-ext report the final result (FAILURE or SUCCESS)?

 

Best regards

 

David

 

jer...@bodycad.com

unread,
Apr 24, 2017, 12:12:44 PM4/24/17
to Jenkins Users, David....@emea.nec.com
You can check the currentBuild status just before sending the email:

currentBuild.result

If empty it mean nothing have set it to warning or error yet. you can set it to success
if(!currentBuild.result)
{
  currentBuild
.result = 'SUCCESS'
}

or you could set it directly into the email without touching the currentBuild.result variable or use another variables into a custom template.

David Aldrich

unread,
Apr 24, 2017, 12:17:56 PM4/24/17
to jenkins...@googlegroups.com

Thanks for your answer.

 

I’m beginning to think that pipeline scripting is too difficult.  It seems to me that there aren’t enough complete examples to demonstrate this stuff.  The snippets generator does not help with putting a complete script together.

 

Jenkins seems to have gone from being very user friendly to difficult L

 

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/dd403b4e-dd28-484b-9c7e-3f8342e6faa6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Click here to report this email as spam.

Slide

unread,
Apr 24, 2017, 12:24:17 PM4/24/17
to jenkins...@googlegroups.com
I'll be completely honest here and say that pipeline isn't for everyone. Not ever build setup needs pipeline. Free style projects are just fine to use still. If they meet your needs, then I don't see a reason to switch to pipeline.

David Aldrich

unread,
Apr 24, 2017, 12:28:08 PM4/24/17
to jenkins...@googlegroups.com

Understood. But the multibranch plugin is marked as deprecated and it seems that the multibranch pipeline is advised.  Multibranch projects are very helpful for us so I thought it would be good to look at pipelines.

 

I guess I may be advised to try Blue Ocean, but that is git-centric and we are svn-centric.  So we’re a bit stuck L

 

jer...@bodycad.com

unread,
Apr 24, 2017, 1:31:43 PM4/24/17
to Jenkins Users, David....@emea.nec.com
It's not so hard, it's just some behavior/limitations that are a bit hard to grasp (groovy loop anyone). I think they went on a road to provide some features at high trade back cost.

If you want some examples more like real life usage:

I would love to have better or complex examples, that would save a lots of questions on this lists and people wouldn't get so frustrated trying to achieve simple stuff.

Some people must have made a few .groovy that could be used by many, that would be great if that could be shared between user, like plugins one day. I made a few python scripts to help me back into the Jenkins non pipeline era, I still use them, but passing them to Groovy would be a pain, since even if I made a normal groovy script, I would still have to validate the Jenkins 'groovy' alike language can output the same thing and probably have to allow a few dozen of functions into scripts approval.

So far, I use simple Jenkins file that launch a lot of console cmd (Python code, msbuild command, batch/bash script, custom C# program) that I can test into console. Work fine, except the Windows slave hang and the new email-ext that doesn't resolve the absolute path on node.

David Aldrich

unread,
Apr 25, 2017, 3:46:22 AM4/25/17
to jer...@bodycad.com, Jenkins Users

I agree that some better examples would help a lot.  In particular, an example script that runs a shell command and provides an email notification would be a great help.

 

> So far, I use simple Jenkins file that launch a lot of console cmd …

 

Please will you post your Jenkins file here or send it to me by email?

 

Best regards

 

David

 

From: jer...@bodycad.com [mailto:jer...@bodycad.com]
Sent: 24 April 2017 18:32
To: Jenkins Users <jenkins...@googlegroups.com>
Cc: David Aldrich <David....@EMEA.NEC.COM>
Subject: Re: How to use email-ext plugin in pipeline script?

 

It's not so hard, it's just some behavior/limitations that are a bit hard to grasp (groovy loop anyone). I think they went on a road to provide some features at high trade back cost.

 

Click here to report this email as spam.

jer...@bodycad.com

unread,
Apr 25, 2017, 9:30:06 AM4/25/17
to Jenkins Users, David....@emea.nec.com
Upon David request here's our Jenkinsfile example, it's not all files should be enough to give a good idea of my current setup.

Note (the email-ext email content stop working between 2.51 and 2.54 Jenkins update, since the absolute path can not be found anymore, I may have to transfer the file back to the master node or something similar).

  • The concept is to have Jenkinsfile alone into it's own mercurial repos.
  • Then as sub repos (JenkinsBuildHelperScripts) I have many template/helper scripts.
  • The LocalSettings.groovy only exist on each node if some installation/properties are special on a particular node.
This is the basic idea, the build system is configured to take 2 parameter:
  • PIPELINE_REPOS
  • PIPELINE_BRANCH_NAME
the default value are set for mostly used script but can be change for testing or if a dev want to check it's own branch or want to compile with another compiler (VS2013, VS2015, VS2017 config branch exist for example)

  1. The master checkout the Jenkinsfile repos (along with it's sub repos since this is a Mercurial behavior). 
  2. Kick in the appropriate node
  3. stage('Init Node') The node checkout Jenkinsfile sub repos again into it's tmp (avoid double checkout into workspace) to get access to build helper scripts (could have been transfer from master to node but checkout is simpler to make sure I got everything). It also make sure the proper env settings are used and it sellect the proper MSBuild/Qt version installed on the node.
  4. stage('Checkout') The actual code checkout
  5. stage('Clean') clean up previous build
  6. stage('Build') launch msbuild compilation for the whole solution
  7. stage('Build Unit Tests') compile the unit tests (google C++ tests)
  8. stage('Run Unit Tests')  I have a python script that help run every .exe of unit test with ADmonitoring, then I collect the core dump and tests results. I also rerun failed tests into html mode, where I can collect the awaited/results comparaison of our tests function and I publish them so user can see what is wrong (we do a lot of 3D, so WebGL with simple geometry can be render with our tests output).
  9. stage('Benchmark') some of our tests output benchmarks, I also have a script that convert the output and log the data between build so I can monitor the algo performance between build.
  10. stage('Qml Syntax Checker')  the Qml syntax checker, run qmlint on each files (output is console parsed later since we can only do it once).
  11. stage('Qml Inspection') same inspect valid Qml structure, qmldir entry
  12. stage('VcxProj Inspection') make sure a dev didn't forget some Optimization into the code and other in house settings. This is the last place where we concat the .txt for the rules and do a single console parsing.
  13. stage('Doxygen Generation') we then generate the doxygen
  14. Send the email with templates based on the build results. This is broken into 2.54 (was working into 2.51): Jelly file [c:/Jenkins/workspace/CAD_CPP/CAD_CPP_ContinuousBuild@tmp/email_template_file.jelly] was not found in $JENKINS_HOME/email-templates.
This is not perfect at all, but it give a good idea of what is possible for us. I haven't play with the declarative pipeline yet. 

What I wish I had:
  1. I would like to have stage that run no matter what (even if previous stage failed)
  2. Easy to express which stage are linear and which can be done into parallel (on same node)
  3. Multiple Console parsing per stage output (super slow since it have to parse the whole output which is totally unnecessary.
  4. email-ext that can take the absolute path template on node again!
  5. Programming language that is 100% compatible with Groovy language so we can test outside Jenkins our scripts. My best fallback is to develop Python and use groovy only to launch those script which remove a lot of pain  (predictable, testable, stand alone development...).



Jenkinsfile
JenkinsEmailVariables.groovy
LocalSettings.groovy
QmlScriptWalker.txt
CppInspection.txt
PipelineXUnitTests.template
PipelineArtifacts.template
PipelineFooter.template
PipelineHeader.template
BcadFunctions.groovy
JenkinsBuildVariables.groovy
Reply all
Reply to author
Forward
0 new messages