Pipeline stage deprecated without block

[jer...@bodycad.com]

Hi,

I now have the following message into my pipeline workflow but I don't really know what exactly is the new proper way of doing it.

Here's a simplified version of what I do

node
{
   stage 'Checkout'
   ...
   stage 'Build'
   ...
   stage 'Build Unit Tests'
   ...
}

but now I see this message for every stage into my console output:

[Pipeline] stage (Checkout)
17:10:09 Using the ‘stage’ step without a block argument is deprecated
17:10:09 Entering stage Checkout

If I check this page:

https://jenkins.io/doc/pipeline/steps/pipeline-stage-step/

versus good call:

https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/

seem like it's deprecated but I don't known what exactly replace it?!? and can I keep the stage view like this?!?

 stage now takes a block argument, what is that argument exactly? what is considered a block?

Thanks

Jerome

[Mark Waite]

Thanks for asking the question!  I see the same message and didn't find an explanation (at least that I understood) of the intention for a block argument in a stage.

Looking forward to the answer..

Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b7ef10d7-5f0c-4d2d-87c1-bcc42ef33144%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Bayer]

Basically, the new syntax is:

stage("Checkout") {

  checkout scm

}

A.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b7ef10d7-5f0c-4d2d-87c1-bcc42ef33144%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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

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

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtGzmn%2Bq8xWrJdYAbR6wYyqX5gNmyCa%2BZxLDDBScYouS%3Dw%40mail.gmail.com.

[Patrick Wolf]

As Andrew mentions a "block" is step that requires a closure.

The original way that 'stage' was implemented left holes in the usability and some features did not work as well as intended. Namely, concurrency and promotion did not work well and it was hard to define the boundaries of a stage.

https://issues.jenkins-ci.org/browse/JENKINS-26107

https://issues.jenkins-ci.org/browse/JENKINS-30269

https://issues.jenkins-ci.org/browse/JENKINS-27039

https://issues.jenkins-ci.org/browse/JENKINS-29892

Rather than replacing 'stage' with a 'label' step we decided to keep and overload 'stage' and deprecate the old syntax that does now work.  In addition, we have added a 'lock' step and will soon add a 'milestone' step to isolate these features and make the behavior more predictable and controllable.

The new 'stage' requires a block to give it defined boundaries but no longer accepts a concurrency value. Concurrency needs to be controlled by the lock step.

This gives much greater flexibility such as:

lock ("resource") {

  stage ("checkout){

    dosomething()

  }

  stage ("build") {

    dosomething()

 }

 timeout(time: 3, unit: 'SECONDS') {
stage ("test"){
}
}

Or any other combination. 'Milestone' will be ready soon and this step will ensure that newer builds continue but older builds are aborted to ensure delivery timing. You can read the details in the ticket.

I was hoping to blog about all of this when 'Milestone' is available. For the time being, nothing will change for the existing 'stage' functionality. You will see the message in your log file but nothing will stop working.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAPbPdOZ4Y4R-4drgiZBOC-2FH%2B5xC4dG47tieTa0BmqSHG1wFA%40mail.gmail.com.

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

--

Patrick Wolf

Product Director - Jenkins 

CloudBees

[jer...@bodycad.com]

ok, great thanks it now have a scope of operation, that was not clear with the error message (at first I was under the impression I needed to give it an argument of some sort:

stage([name:'checkout', block: ???])

Now it's clear.

[Daniel Beck]

> On 02.09.2016, at 14:45, jer...@bodycad.com wrote:
>
> ok, great thanks it now have a scope of operation, that was not clear with the error message (at first I was under the impression I needed to give it an argument of some sort:

Well, you do. It's just that you place the block outside the parentheses to make it look nicer.

http://groovy-lang.org/style-guide.html#_omitting_parentheses

> When a closure is the last parameter of a method call, like when using Groovy’s each{} iteration mechanism, you can put the closure outside the closing parentheses, and even omit the parentheses:

[Ron Dagostino]

This is not working as I expected, and I am wondering if I am doing something wrong/operating under an incorrect assumption or if I am encountering a bug.  I have this in my Jenkinsfile:

node('some_non_master_node') {
    stage('Upload/Trigger') {
        timeout(time: 2, unit: 'MINUTES') {
            lock(env.JOB_NAME) {

When I run the job in isolation it works fine:

Trying to acquire lock on [Testing/testrepo1/master]
Lock acquired on [Testing/testrepo1/master]

...

Lock released on resource [Testing/testrepo1/master]
Finished: SUCCESS

Likewise, if I go to https://mymaster.mycompany.com/lockable-resources/ and manually reserve the resource before starting the job, I see the timeout as expected:

Trying to acquire lock on [Testing/testrepo1/master]
[Testing/testrepo1/master] is locked, waiting...
Timeout has been exceeded
Finished: ABORTED

The unexpected behavior occurs if I manually reserve the resource before the job starts and then immediately free the resource once the "[Testing/testrepo1/master] is locked, waiting..." message appears.  The job times out instead of detecting that the resource has become available.

Am I doing something wrong/operating under a wrong assumption, or is this a bug?

Ron

[Ron Dagostino]

The behavior I am seeing is a known bug.

https://issues.jenkins-ci.org/browse/JENKINS-34433
"pipeline lock does not retry"

Ron