[DISCUSS] Two new basic pipeline steps: forBranch() and forChangesIn()

[georg....@netcentric.biz]

Hi all, 

we've been using the Jenkins pipelines pretty much from the day when they were released. As we use a fairly standardised build process across all projects in our organisation, we use shared libraries heavily to avoid redundancy across the repositories' Jenkinsfiles. For two little functionalities, I would propose to promote them to "official build steps" written in Java and hence available to the broader Jenkins community:

forBranch("feature/.*") {

    // only executed if on feature branch (if regex matches)

}

forChangesIn(".*/apache-config/.*") {

   // somehow apply apache config, but only if it has changed

}

The implementation of forBranch() is fairly trivial, it only checks for env.BRANCH_NAME and matches against the given regex. forChangesIn() is a bit more complicated (iterating over all changesets of all SCMs), but also fairly straight-forward. 

forBranch() would help making Jenkinsfiles better readable and concise (obviously the same can be done with an if, but comparing the two versions shows clearly that the if-variant introduces a more boilerplate).

forChangesIn() is a functionality that I believe is not readily available yet (correct me if I'm wrong!)

The two steps could be put directly in workflow-basic-steps-plugin or maybe in pipeline-utility-steps-plugin. forBranch() potentially would be better suited for workflow-multibranch-plugin. 

WDYT?

-Georg

[Jesse Glick]

Declarative Pipeline certainly can easily do the same as `forBranch`,
and from Scripted you can trivially write the same thing, so I think
no new step is warranted.

Not quite sure I follow what `forChangesIn` is about, but sounds like
a candidate for a new plugin.

[Robert Sandell]

Yes declarative has both of these in a way via the when directive's branch and changeset conditions. If I've interpreted forBranch and forChangesIn correctly :)

https://jenkins.io/doc/book/pipeline/syntax/#when

/B

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0jXNj9-XCTWXERUQz%2B7Vx9sVrPor%2BraJU-GSHvaoMsWw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees, Inc.

E: rsan...@cloudbees.com

Twitter: robert_sandell

[Jesse Glick]

On Thu, Apr 12, 2018 at 5:13 AM, Robert Sandell <rsan...@cloudbees.com> wrote:
> Yes declarative has both of these in a way via the when directive's branch and changeset conditions. If I've interpreted forBranch and forChangesIn correctly

`forChangesIn` sounded to me like something different—running its
block repeatedly somehow?—but I did not really grasp what it was
about. Probably best demonstrated by just writing the plugin for it
and submitting the hosting request.

[thorste...@taimos.de]

I think this will be a way to support those two features. Is "when" also possible in scripted pipelines?

Am Donnerstag, 12. April 2018 11:13:28 UTC+2 schrieb Robert Sandell:

Yes declarative has both of these in a way via the when directive's branch and changeset conditions. If I've interpreted forBranch and forChangesIn correctly :)

https://jenkins.io/doc/book/pipeline/syntax/#when

/B

2018-04-11 23:39 GMT+02:00 Jesse Glick <jgl...@cloudbees.com>:

Declarative Pipeline certainly can easily do the same as `forBranch`,
and from Scripted you can trivially write the same thing, so I think
no new step is warranted.

Not quite sure I follow what `forChangesIn` is about, but sounds like
a candidate for a new plugin.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0jXNj9-XCTWXERUQz%2B7Vx9sVrPor%2BraJU-GSHvaoMsWw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Jesse Glick]

On Fri, Apr 13, 2018 at 1:14 AM, <thorste...@taimos.de> wrote:
> Is "when" also possible in scripted pipelines?

You would just use `if` statements and the like.

[Georg Henzler]

> Yes declarative has both of these in a way via the when directive's branch and changeset conditions. If I've interpreted forBranch and forChangesIn correctly :)

Thanks Robert, this is exactly it (we are using scripted pipelines for their flexibility, I was not aware of this syntax in the declarative ones)

So what about bringing the functionality of "when(changeset ...)" over to the scripted pipelines? (maybe as proposed as forChangesIn(), but I see some people didn't understand it, so maybe whenChangesIn() or similar is better, other suggestions?). One thing I'd like to see though is to have the ability to specify RegEx over ant glob patterns - RegEx is as simple as the glob patterns for simple cases, but can cover any complicated cases as well (where the glob patterns are quickly limited)

Regarding forBranch()

> You would just use `if` statements and the like.

Exactly, you can. 

My Point was though that it would be nice to have the syntax [2] because syntax [1] is not as readable.

[1]

... build (that is usually the same for all branches)....

if (env.BRANCH_NAME.startsWith("feature/") || env.BRANCH_NAME.startsWith("bugfix/")) {

      // enforcers validation only necessary on new code before merging

}

if (env.BRANCH_NAME.startsWith("develop") || env.BRANCH_NAME.startsWith("feature/")) {

      // integration test not on bug fix branches

}

if (env.BRANCH_NAME.startsWith("develop")) {

     // deployment to a dev environment, automatic

}

if (env.BRANCH_NAME.startsWith("develop") || env.BRANCH_NAME.startsWith("release")) {

      // deploy to a validation environment used by CQ (manual trigger, they chose which branch they use)

}

[2]

... build (that is usually the same for all branches)....

forBranch("(feature|bugfix)/.*") {

   // enforcers validation only necessary on new code before merging

}

}

forBranch("develop|feature/.*") {

   // integration test not on bug fix branches

}

forBranch("develop") {

     // deployment to a dev environment, automatic

}

forBranch("develop|release/.*") {

    // deploy to a validation environment used by CQ (manual trigger, they chose which branch they use)

}

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/mDLg7W6Xq68/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr051Mhd8PtLfdbDzq5GFZbGFMgqwVQFAZ4CCrh88%3D%3D6tA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Georg Henzler
Principal Solution Architect

georg....@netcentric.biz

M: +49 171 92 46 474

Netcentric, A Cognizant Digital Business | www.netcentric.biz
Follow us on LinkedIn | Twitter
Other disclosures according to § 35a GmbHG, § 161, 125a HGB: www.netcentric.biz/imprint.html

This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful.