Loading and displaying file content using the Customize Task Description Template

[Bill Matzen]

I've just started using the Delivery Pipeline plugin and it's excellent, and I was so excited to see the options that can be used in the Customize Task Description Template, especially ones that can load content from a file. However it looks like it only looks at files based off of the Workspace as opposed to the specific build folders.  According to the help for PROPFILE, FILE, and XML, the files are "relative to the build workspace root".  

I'd been hoping to display file content per-build of the job.  For example, we'll enter a root cause description for a failed build using the build description, which ends up in /Jenkins/jobs/[job name]/builds/[build number]/build.xml, at xpath /build/description/text().  So I was trying: ${XML,file="build.xml",xpath="/build/description/text()"}. It doesn't find build.xml here, however, but does when I manually copy it to the workspace that the build last ran under (on a slave agent as it were) - I did this simply to confirm where it is looking. I can think of quite a few use cases for Customize Task Description Template that would be useful if it looked at the build folder for passed builds, and only looked at the workspace for the current build (or for consistency potentially just always looks at the build folder and I manage copying the file there while the build is running).

Has anyone else done much with Customize Task Description Template referencing files (PROPFILE, FILE, or XML) and can confirm (or correct me on) this behavior?  I appreciate any help.

Thanks,
Bill

[Patrice Matignon]

Bill,

Maybe I'm missing something, but if you leave the " Customize Task Description Template" field empty, and then the Build Description will be used automatically and displayed in the Pipeline.

As you may already know, you can set the Build Description automatically based on some RCA/log parsing (or even manually) at he end of the build (e.g. post-build actions).

Now, in the Edit View configuration, you need to check "Show Job Description" (which would be more accurately worded as "Show BUILD Description"...), otherwise nothing shows.

[Bill Matzen]

Hi Patrice - I feel like such an idiot. =P  I actually just noticed that behavior this morning (after giving up and clearing the field this morning) and then saw your post - I was obviously overthinking that one! :)  I had a few other ideas for things to display which included loading data from files, but I clearly picked the wrong one to use as an example.  That is super handy, and yes we will manually update the Build Description with a synopsis of why a build failed so others can see via the Delivery Pipeline.  That will work great.

For displaying other information from files, however, it nevertheless still appears to be looking at the workspace and not the build directory. So for example if I wanted show per-build content in that field:

    I'd like to load from here - unique per build:

        /Jenkins/jobs/[job name]/builds/[build number]/

    Customize Task Description Template seems to look here instead - not unique per build

        /Jenkins/workspace/[job name]/

Unless Jenkins automagically knows to look under the per-build folder if a build has completed, versus the workspace if it's still running, but I'm guessing not. :)  I imagine that's up to the plugin to control that behavior.

Bill

[Patrice Matignon]

Bill,

I think the premise of accessing files directly on the master's filesystem is a bit dangerous. These files are meant to persist live or historical entities that can be accessed transparently via the API's.

Therefore I suggest you look into 2 distinct options here to leverage API's in your context..

- The first one is to use the Groovy API which should let you access the specific build object and give you access to the properties persisted in the build's xml file on the server. Or access other information persisted on the server but not readily available as a direct env var in the context.

- The second option is more clunky, and consists of using the REST api to access anything that Jenkins will share about any entity in JSON or XML format.

Let me know fi that sounds like a good route for you and if you need more pointers in realizing it.

[Bill Matzen]

Thanks Patrice.  That's a good point about the security issue of accessing the master's filesystem.  Given that we (now) have a good way to access the build description (shows by default in the Delivery Pipeline) once a build has completed, our only need for loading file content via Delivery Pipeline is for builds that are currently running, and so the fact that were restricted to the build's workspace is fine in this case.  Thus our plan is to use the Delivery Pipeline's display for two purposes, first for showing build descriptions for past builds (leaving Customize Task Description Template blank), and second for showing in-progress status messages (using Customize Task Description Template to load the message from a file in the workspace - which we'll update dynamically).  Thanks for your help on this.

[Bill Matzen]

Actually now that I think of it, there's a hole in my logic here.  What I've proposed actually requires changing Customize Task Description Template on the fly, and even then, if I'm displaying some file content from the workspace, it'll show that for every instance of the job in the display. What I really want is for separate per-build behavior depending on whether the build is running or is one that has completed. Thus the GROOVY option!  Check the current build, and if it's running. If so, return the file content, if not, show the build description.  Perfect...

...except I can't get the GROOVY option to work! =P  According to the help:

    ------------------------

    ${GROOVY,script = "code"}

    Executes Groovy code
    Example:
    ${GROOVY,script = "return jenkins.model.Jenkins.instance.pluginManager.plugins"}
    Note:
    By default, the support for token macro pressing is switched off and has to be switch on in global config page.
    Warning:
    If token macro processing via Token Macro Plugin is allowed, the evaluation of macro is done in System Groovy, therefore any user can run arbitrary system script, regardless he has administer permission!

    ------------------------

I tried the example, and it simply displays the text in quotes ("return jenkins.model.Jenkins.instance.pluginManager.plugins").  Likewise a simple ${GROOVY,script = "return 'Hello, world!'"}.  Considering the note about "token macro processing", I tried enabling that.  Doing so now causes the display to show: 

    "Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 1, pos 44): ${GROOVY,script = "return 'Hello, world!'"} ^ java.lang.ClassCastException: hudson.util.StreamTaskListener cannot be cast to hudson.model.BuildListener"

Has anyone had any luck running groovy script in Customize Task Description Template?

Thanks,
Bill

[Patrice Matignon]

Bill,

Indeed, I've never had much luck, but I didn't want to open up the Groovy Macro token processing either.

I think you can get away by always displaying the Build Description (default) and set the build description several times during the build (Build Step - "Set build Description" ) or afterwards (POST-Build Step - "Set build Description"  - you are most likely already doing that), which lets you set the Build Description from a build log entry. You can also use the Build Step "execute System Groovy script" to manipulate the build object and its description (e.g. build.setDescription "Hello World!" ).

[Bill Matzen]

I was just hoping to update the description using a process externally to the jenkins build step (which is stuck running a single long-running batch command). It may get updated 10 or 20 times during the build step.  And while a work-around would be to split the job into 10 or 20 smaller build steps, updating the build description in between each one, that's very ugly. :)  I'll probably look into debugging into the plugin to try to understand why the groovy script isn't working (although I suppose I could enter a defect if it's not just me having problems with it).