Support declarative pipeline syntax

[ozangunalp]

Support for testing declarative pipeline syntax.

Provides a DeclarativePipelineTest base class that

• Does syntactic checking of the declarative pipeline model
• Mocks the ModelInterpreter provided by the pipeline-model-definition-plugin and sets props/params/credentials etc. and calls steps on stages, with when predicates and post actions.

Yet there are several caveats with this approach:

• It does not verify whether there is any if,else,loop instructions on regular steps blocks,
• Mock model interpreters should be easily extensible by users, which is not possible for now. For now the only extension point is the pipeline keyword, which involves rewriting every model interpreter.
  DeclarativePipelineTest does not use CPS transformation so it does not verify the pipeline against serialization issues.

[jdoshi1]

@ozangunalp - This is pretty good stuff. When will this Pull-request be merged to master?

[crasp]

Works fine with all our declarative pipeline scripts. Had to add an additional dependency org.assertj:assertj-core:3.4.1 for the build.

[ozangunalp]

@crasp @jdoshi1 thanks for testing this pull request.
I prepared this PR a while ago and as I wrote in the description back then, I would like to find a solution that is extensible.

I honestly fear that the declarative pipeline syntax will evolve and with this solution we won't be able to follow it.

I'll try to look a bit more and eventually release it as experimental for everyone's use.

Thanks again for checking out the PR.

[benemon]

Any chance of an update on this issue? JenkinsPipelineUnit is a great tool, and as the Declarative method becomes more widely used it's going to be critical that Pipelines be tested properly.

[kmadel]

Any chance this will get merged or a reason it shouldn't be merged?

[cavdhut]

When this will be released?

[crasp]

@kmadel @cavdhut as mentioned above it does not work very well together with declarative syntax. There have been evolving some other projects that cover this at this years Jenkins World, like https://github.com/homeaway/jenkins-spock. Maybe you can check this out as well.

[benemon]

@crasp there comes a point where you have to start thinking about marking a repository which sits underneath the Jenkins community umbrella as either deprecated, or looking for new maintainers. It would help give potential adopters a direction of travel, if nothing else.

As is evidenced by this and other PRs / Issues, there is clearly more than enough interest in a tool like JenkinsPipelineUnit to warrant a bit more love than it currently gets, and I for one would rather use a testing tool attached to an 'official' organisation in GitHub rather than some random repository overseen by an individual. In theory, being attached to an organisation implies ongoing maintainence and support (unless stated otherwise) - whereas you just can't get that level of comfort from a random individuals' repo, no matter how good the content initially.

[ozangunalp]

Hi @benemon,

I totally agree on your point about individuals maintaining (or not) repos sitting under the organization umbrella.

In the past year I did not had time to give the love that this community deserves to JenkinsPipelineUnit project.

In my defense, in the past months we had been talking with the Jenkins team to onboard at least one other maintainer to the project to get things going and keep the project up to date. I do not know why things did not advance, but i will make sure we have updates ASAP.

As for this PR, it was a proof of concept investigating the viability of the declarative pipeline support for JPU. I come to the decision that keeping up to date the declarative DSL syntax – with possible extensions etc. – would not be feasible and i chose to not advance in its development.

I understand very well the need to test a Jenkins pipeline and secure it's execution against regressions, but for the classic imperative DSL pipelines and libraries.

Unless I missed something during the past months declarative pipelines have a standard lifecycle for stage composition and error handling, and it does not have conditional logic or complex configuration. I think it is a great way to write jenkins pipelines and simplify the common tasks with CI/CD pipelines.

Even though I am open for discussion about the subject, I do not see the need to test declarative pipelines in JPU and when I discussed (a year ago) with the Jenkins team we came up with the same conclusion.

That said the Spock specifications provided by the cited project seems like a decent way if someone insists on testing declarative pipelines.

I am again sorry for the frustration that I caused on the maintenance of this project, and promise to get things going in the near future.

Ozan

[benemon]

@ozangunalp

Thanks for the prompt response, it is very much appreciated. Please understand that my comments are in no way a reflection of the time and energy you have clearly spent with this project.

There's a lot of potential here that would be a shame to go to waste, given the clear interest from the community in JPU. With that in mind, its really good to hear that you've been having talks about extending the maintainence team around the repository. I'm not even talking solely about Declarative Pipelines.

I'll raise an issue for it, but it would be great to get a roadmap or at least a tentative understanding of timelines and objectives around this project and how you see it developing in the future.

[ozangunalp]

@benemon thanks for the understanding.
I will get back to you with more info.

[andyfeller]

@stchar : you're a hero ❤️