re: What Tools Do You Use To Validate Jenkins Pipeline Syntax VIEW POST

re: I wouldn't change what you're doing. Jenkins very much wants to be utilized in the same manner. If you can shell out to CLI tools to accomplish tas...

I'd probably do more stuff in the DSL if the plugins I wanted to use were more "on board" with the pipeline thing. Seems like the bulk of the plugins (at least the ones our user-community requests) were designed for "Freestyle" usage rather than pipeline usage ...frequently meaning have to go read the plugin's source-code to suss out the "which of these bits are usable in Pipeline mode." Usually, it's just quicker/easier to use the OS-native tools via a sh() statement than try to do things The Right Way™

This is doubly so when, the reason I'm dicking with Jenkins-managed jobs is because the primary customer for the devops tooling keeps harping on "we need to eat our own dogfood". I find myself struggling with the "why would I waste already over-commited time wrapping shit in Jenkins when I can just use the AWS CLI directly". Adding the pipeline layer doesn't really seem to be more "infrastructure as code" than is directly-maintaining CFns and CFn parameter-files in relevant git projects. Maybe there's something that's "too obvious" that I'm missing it. :p

I'll admit, though, that I'm a curmudgeon. To me, when you aggregate the knowledge required to use all of these "simplified" tools, you actually require more in the way of specific knowledge than if you just did things "the hard way" (see: all the various simplified markup languages like Markdown, Textile ...and then all of their variants). But, I'm looking at these things from the standpoint of the person charged with fielding and operating all the tools rather than our users who typically only use one or two of the tools (frequently after someone like me has created the further-simplifying automation for them).

Oh. Wow. Wasn't really meaning for that to turn into a rant! =)

If it comes to it you can invoke plugins manually in the DSL, like these for coverage/lint reports:

    $class: 'CoberturaPublisher',
    autoUpdateHealth: false,
    autoUpdateStability: false,
    coberturaReportFile: '**/cobertura-coverage.xml',
    failUnhealthy: false,
    failUnstable: false,
    maxNumberOfBuilds: 0,
    onlyStable: false,
    sourceEncoding: 'ASCII',
    zoomCoverageChart: false

step([$class: 'CheckStylePublisher',
    canRunOnFailed: true,
    defaultEncoding: '',
    healthy: '100',
    pattern: 'eslint.xml,**/nsp.xml',
    unHealthy: '90',
    useStableBuildAsReference: true

True... But that's part of what I was alluding to when saying you frequently need to dig through the GUI-oriented plugins' source to find the names of the knobs to turn via the DSL.

code of conduct - report abuse