Improve pipeline enablement and making it optional

Now using Jenkins pipelines is becoming the norm instead of the weird-use-case and we do need an improved way to enable the AnsiColorBuildWrapper.

Have a look at the Timestamper plugin which now supports the nice DSL syntax:

timestamps {
    // code goes here
    }

To make the usage even better I would like to be able to have some kind of condition: if ansi plugin is present enable it, or continue if not.

With these two small additions we could write much better Jenkins pipelines and we would avoid unpleasant surprises if it happens to have the plugin not installed. Build will continue, which is much better than having it broken because the ansicolor plugin was missing.

PS. Please mind that’s possible for the plugin to be broken at some point and that’s why is much better not to break continuity and continue to work without the feature. Optionally we could throw a warning message, but what matters is to avoid breakages.

[JeanMertz]

Quick question:

Why should I as a Jenkinsfile maintainer be concerned about enabling/disabling color output?

Shouldn’t this plugin simply be activated on the server-side, and “just work” for any pipelines running, with or without color output?

My frame of reference here is all the other hosted CI solutions out there (Travis, CircleCI, etc, etc) that have colouring “enabled by default”, I’ve never seen any ci-specific file in a GitHub project that explicitly enabled colouring, not even just “enable/disable for this project”, let alone “enable for this line”.

I’m sure I’m missing some technical context on why this is ill-adviced/difficult, but I’m looking at it from an end-user perspective.

[subos2008]

@dblock yes, I think reading through it that the OP’s request is satisfied. There is also the request from @markhu that we have a way to enable this globally (which I am 100% in favour of) but that was already requested separately in [https://github.com/dblock/jenkins-ansicolor-plugin/issues/2]