From 7239fd301f500734f75059af439747669b41728a Mon Sep 17 00:00:00 2001 From: Liam Newman Date: Wed, 15 Feb 2017 00:18:12 -0800 Subject: [PATCH] Removed dead words --- .../2017-02-15-declarative-notifications.adoc | 56 ++----------------- 1 file changed, 6 insertions(+), 50 deletions(-) diff --git a/content/blog/2017/2017-02-15-declarative-notifications.adoc b/content/blog/2017/2017-02-15-declarative-notifications.adoc index a81c9ce0f1ba..b4ba578c4a3a 100644 --- a/content/blog/2017/2017-02-15-declarative-notifications.adoc +++ b/content/blog/2017/2017-02-15-declarative-notifications.adoc @@ -275,7 +275,7 @@ pipeline { ---- <1> The `_` here is intentional. link:https://en.wikipedia.org/wiki/Java_annotation[Java/Groovy Annotations] -such `@Library` must be applied to an element. +such as `@Library` must be applied to an element. That is often a `using` statement, but that isn't needed here so by convention we use an `_`. .vars/sendNotifications.groovy @@ -332,26 +332,15 @@ image::/images/post-images/2017-02-15/mailcatcher.png[MailCatcher List, role="ce == Conclusion -In this post, we added notifications to our Declarative Pipeline. -However, Declarative Pipeline prevented us from defining a method in our `Jenkinsfile` to send notifications. +In this post we added notifications to our Declarative Pipeline. +We wanted to move our repetitive notification code into a method; +however, Declarative Pipeline prevented us from defining a method in our `Jenkinsfile`. Instead, with the help of the Shared Library feature, -we were able to define a `sendNotifications` method that we could call from our `Jenkinsfile`. -This maintained the clarity of our Pipeline and will let us easily reuse that code in other projects. +we were able to define a `sendNotifications` Step that we could call from our `Jenkinsfile`. +This maintained the clarity of our Pipeline and will let us easily reuse this Step in other projects. I was pleased to see how little the resulting Pipeline differed from where we started. The changes were restricted to the start and end of the file with no reformatting elsewhere. -This is a great example of how Declarative Pipeline -can help us write clearer, more maintainable Pipelines. -The limitations of Declarative guided us naturally to separate our -Pipeline into two levels: an overall flow and individual steps. -Declarative Pipeline provides a structured way of *declaring* the overall flow of Steps in our Pipeline. -The complex logic and technology-specific work is handled by Steps. -While many Steps come from plugins, Declarative isn't concerned about how Steps are implemented. -Here we've created a Step using a groovy method called -`sendNotifications` that takes a parameter and does some work based on that. -This lets us manage the overall structure of our Pipeline without -getting caught up in how individual Steps are implemented. - In the next post, we'll cover more about shared libraries and how to run Sauce OnDemand with xUnit Reporting in Declarative Pipeline. @@ -362,36 +351,3 @@ run Sauce OnDemand with xUnit Reporting in Declarative Pipeline. * link:/doc/book/pipeline/shared-libraries/[Shared Library reference] * link:https://github.com/bitwiseman/hermann/tree/blog/declarative/notifications[Pipeline source for this post] * link:https://github.com/bitwiseman/jenkins-pipeline-shared/tree/blog/declarative/notifications[Pipeline Shared Library source for this post] - - -//// -// TODO: still re-editing this section. -.Declarative is still Jenkins Pipeline -**** -Looking at the method definition above, some of you will be saying, -"Wait a minute, wasn't Declarative Pipeline supposed to get me away from -Groovy, function definitions, and conditional logic?" -When I first saw this, that's certainly what I said, only with a few more expletives. - -Once I got past the original shock and started working with it, -I found that Declarative still being Groovy was actually a huge advantage. -Declarative Pipeline - everything inside the `pipeline {}` section - -is a -link:https://en.wikipedia.org/wiki/Domain-specific_language[domain specific language] -that uses Groovy syntax, -and outside the `pipeline {}` section -we can still access all the facilities of Groovy and Scripted Pipeline. - -Jenkins Declarative Pipeline is still *Jenkins Pipeline*. - -This meant, as an expert in Scripted Pipeline, I was already familiar with the -basic syntax of Declarative Pipeline. -For users entirely new to Jenkins Pipeline, I think this the same will be true in the other direction - -the basic syntax of Declarative Pipeline is good introduction to the Groovy syntax that is -used throughout Pipeline. -As we'll see in the remainder of this post, Declarative and Scripted Pipeline both being Groovy -makes building up from simple to more complex Pipelines much smoother. - -**** - -////