[JIRA] (JENKINS-43820) Stage name must be a string literal

[kevin.lannen@gmail.com (JIRA)]

Kevin Lannen commented on JENKINS-43820

Re: Stage name must be a string literal This is a serious blocker to using the declarative syntax to define a pipeline in a shared library. What is the "conscious design decision" that led to this? From my perspective there is no downside to allowing this flexibility. Add Comment

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)

[nimrod7@gmail.com (JIRA)]

Kasia Gauza commented on JENKINS-43820

Re: Stage name must be a string literal

Andrew Bayer please explain why it's not possible. Now I am not able to reuse stages, because I must hardcode the text.

Add Comment

[thiago.davila@serpro.gov.br (JIRA)]

Thiago D Avila commented on JENKINS-43820

Re: Stage name must be a string literal

Andrew Bayer what is the recommended workaround to generate stages at runtime? I'm developing template stages in shared-libraries and wanted to create a stagename passed by parameter. If this is a design decision there must be a recommended way, or it imposes limitations to the use of declarative pipelines.

Add Comment

This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

[jeezusjr@gmail.com (JIRA)]

Jesus Alvarez commented on JENKINS-43820

Re: Stage name must be a string literal

This is a silly "conscious design decision" as it eliminates the possibilities of stage names generated from dynamic variables.   environment { BUILD = "Release" } stage ("Building ${BUILD}") { steps { // blah } } In order to get this to work I have to drop the stage in a pipeline library. This sucks! I guess i'll have to live with my ghetto fix: environment { BUILD = "Release" } stage ("Building}") { steps { println "${BUILD} branch, this extra line is crap" // blah } }

Add Comment

[nico.mommaerts@gmail.com (JIRA)]

Nico Mommaerts commented on JENKINS-43820

Re: Stage name must be a string literal

Conscious decision? Let the users decide how to use the system... in a world of job-dsl, automation, devops etc this a serious blocker. Please reconsider this.

Add Comment

[marcello.romani.enit@gmail.com (JIRA)]

Marcello Romani commented on JENKINS-43820

Re: Stage name must be a string literal

Andrew Bayer, do you have a pointer to documentation that explains this limitation? I know this has been asked before, but it looks like quite an annoying shortcoming. Thanks!

Add Comment

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

[socialguy@outlook.com (JIRA)]

Abhijit Sarkar commented on JENKINS-43820

Re: Stage name must be a string literal

Andrew Bayer once you get off your high horse, please consider fixing what was clearly pulled out of a hat.

Add Comment

[adam@diginc.us (JIRA)]

Adam BH commented on JENKINS-43820

Re: Stage name must be a string literal

Since no response is being made by CloudBees my best guess is they wanted to encourage static stage names because the legacy build history (not BO, maybe others too) view shows history best when stages don't change names dynamically. Anyone who has ever changed stages over time knows their history on this view gets reset when doing. My use case for this wasn't to change the stage name(s) between builds but just to avoid some repeated strings with a variable used by a bool parameter (the key, not value), my label, and my stage name. I'll echo others, this feels rather arbitrary and the silence is more frustrating than 'No because X'...the key part being 'because X'.

Add Comment

[HighlandLogan@JohnDeere.com (JIRA)]

Logan Highland commented on JENKINS-43820

Re: Stage name must be a string literal

Andrew Bayer I would also appreciate the reasoning behind this decision. It seems that for an unknown reason you are not implementing something that would be very helpful, and any explanation as to why this isn't feasible would be greatly appreciated. Thanks.

Add Comment

[morgan@resapphealth.com.au (JIRA)]

Morgan Robertson commented on JENKINS-43820

Re: Stage name must be a string literal

I too would like to add my support behind this request.  Just like code should be readable, so should a UI.  I want my users to be able to glance at a blue ocean build & know what's happening without having to trawl though build logs.

Add Comment

[morgan@resapphealth.com.au (JIRA)]

Morgan Robertson edited a comment on JENKINS-43820

Re: Stage name must be a string literal

I too would like to add my support behind this request.  Just like code should be readable, so should a UI.  I want my users to be able to glance at a blue ocean build & know what's happening without having to trawl though build logs. [~abayer] please consider reopening this issue.

Add Comment

[jeremy@mathevet.net (JIRA)]

Jeremy Mathevet commented on JENKINS-43820

Re: Stage name must be a string literal

Please reconsider! There are some cases where this could be useful.

Add Comment

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[larry_west@intuit.com (JIRA)]

Larry West commented on JENKINS-43820

Re: Stage name must be a string literal

Andrew Bayer - a "design decision" that neither satisfies the customer nor addresses some inherent constraint is indistinguishable from a design flaw. Please have someone else in your organization – who is not invested in this "design decision" – re-evaluate this. Thanks!

Add Comment

[larry_west@intuit.com (JIRA)]

Larry West updated an issue

Jenkins / JENKINS-43820

Stage name must be a string literal

Change By: Larry West Comment: [~abayer] - a "design decision" that neither satisfies the customer nor addresses some inherent constraint is indistinguishable from a design flaw.

Please have someone else in your organization – who is not invested in this "design decision" – re-evaluate this. Thanks!

Add Comment

[yotu.tuy@gmail.com (JIRA)]

Karolina Arancibia Valuskova commented on JENKINS-43820

Re: Stage name must be a string literal This worked for me (Jenkins ver 2.190.1): stage ("Deploy ${BRANCH_NAME}")

Add Comment

[chris@chrishemp.com (JIRA)]

Chris Hemp commented on JENKINS-43820

Re: Stage name must be a string literal

Karolina Arancibia Valuskova is that with scripted pipeline or declarative syntax? I tried above inside declarative syntax (`pipeline {...}`) and above did not work.

Add Comment

[dave.cashin@ca.ibm.com (JIRA)]

david cashin commented on JENKINS-43820

Re: Stage name must be a string literal

Also asking this be reopened, this would be very helpful to have

Add Comment

[ironchamp@gmail.com (JIRA)]

Alan Champion commented on JENKINS-43820

Re: Stage name must be a string literal

For good coding practice, at least static variables ought to be considered. I appreciate why stage names on any given pipeline ARE expected to be stable and concise. However,  please reconsider for fixed variables assuming a pre-pass of pre-declared env. variables would be useful since convenient for ease of maintenance across multiple stages, especially when cloning (or generating) similar pipelines. pipeline { environment {   ENV = 'DEV'   PHASE = 'IT'   DELIVERY = "DELI"   BASE = "REGI" } stages {   stage('1.  Prepare ' + PHASE + ' DB')     steps {       script {         println "Prepare " + PHASE + " to clean " + DELIVERY + " & " + BASE + " schemas within ${env.ENV} DB"          :       }     }   }   stage('2.  Generate ' + PHASE + 'Tests)     steps {       script {         println "Generate " + PHASE + " for exec in both " + DELIVERY + " & " + BASE + "  ${env.ENV} environments"          :       }     }   }   // Exec parallel $PHASE tests   : } }

Add Comment

[ironchamp@gmail.com (JIRA)]

Alan Champion edited a comment on JENKINS-43820

Re: Stage name must be a string literal

For good coding practice, at least static variables ought to be considered.

I appreciate why stage names on any given pipeline ARE expected to be stable and concise. However,  please reconsider for *fixed* variables assuming a pre-pass of pre-declared env. variables would be useful since convenient for ease of maintenance across multiple stages, especially when if cloning (or generating) similar pipelines for different phases/environments . pipeline { environment {

{   ENV = 'DEV'   PHASE = 'IT'   DELIVERY = "DELI"   BASE = "REGI" } stages {   stage('1.  Prepare ' + PHASE + ' DB')     steps {       script {         println "Prepare " + PHASE + " to clean " + DELIVERY + " & " + BASE + " schemas within ${env.ENV} DB"          :       }     }   }   stage('2.  Generate ' + PHASE + 'Tests)     steps {       script {         println "Generate " + PHASE + " for exec in both " + DELIVERY + " & " + BASE + "  ${env.ENV} environments"          :       }     }   }   // Exec parallel $PHASE tests   : } }

Add Comment

[ironchamp@gmail.com (JIRA)]

Alan Champion edited a comment on JENKINS-43820

Re: Stage name must be a string literal

For good coding practice, at least static variables ought to be considered.

I appreciate why stage names on any given pipeline ARE expected to be stable and concise. However,  please reconsider for *fixed* variables assuming a pre-pass of pre-declared env. variables since convenient for ease of maintenance across multiple stages, especially if cloning (or generating) similar pipelines for different phases/environments.

pipeline { environment {   ENV = 'DEV'   PHASE = 'IT'   DELIVERY = "DELI"   BASE = "REGI" } stages {   stage('1.  Prepare ' + PHASE + ' DB')     steps {       script {         println "Prepare " + PHASE + " to clean " + DELIVERY + " & " + BASE + " schemas within ${env.ENV} DB"          :       }     }   }

stage('2.  Generate ' + PHASE + 'Tests ' )

steps {       script {         println "Generate " + PHASE + " for exec in both " + DELIVERY + " & " + BASE + "  ${env.ENV} environments"          :       }     }   }   // Exec parallel $PHASE tests   : } }

Add Comment

[ironchamp@gmail.com (JIRA)]

Alan Champion edited a comment on JENKINS-43820

Re: Stage name must be a string literal

For good coding practice, at least static variables ought to be considered , even in DSL .

I appreciate why stage names on any given pipeline ARE expected to be stable and concise. However,  please reconsider for *fixed* variables assuming a pre-pass of pre-declared env. variables since convenient for ease of maintenance across multiple stages, especially if cloning (or generating) similar pipelines for different phases/environments. pipeline { environment {   ENV = 'DEV'   PHASE = 'IT'   DELIVERY = "DELI"   BASE = "REGI" } stages {   stage('1.  Prepare ' + PHASE + ' DB')     steps {       script {         println "Prepare " + PHASE + " to clean " + DELIVERY + " & " + BASE + " schemas within ${env.ENV} DB"          :       }     }   }   stage('2.  Generate ' + PHASE + ' Tests')     steps {       script {         println "Generate " + PHASE + " for exec in both " + DELIVERY + " & " + BASE + "  ${env.ENV} environments"          :       }     }   }   // Exec parallel $PHASE tests   : } }

Add Comment

[ironchamp@gmail.com (JIRA)]

Alan Champion edited a comment on JENKINS-43820

Re: Stage name must be a string literal

For good coding practice, at least static variables ought to be considered, even in DSL.

[~abayer] - I appreciate why stage names on any given pipeline ARE expected to be stable and concise . However,  please can you kindly reconsider for * fixed constant * variables assuming a pre-pass of pre-declared env. variables , since convenient for ease of maintenance across multiple stages, especially if after cloning (or generating) similar pipelines for different phases/environments.

pipeline { environment {   ENV = 'DEV'   PHASE = 'IT'   DELIVERY = "DELI"   BASE = "REGI" } stages {   stage('1.  Prepare ' + PHASE + ' DB')     steps {       script {         println "Prepare " + PHASE + " to clean " + DELIVERY + " & " + BASE + " schemas within ${env.ENV} DB"          :       }     }   }   stage('2.  Generate ' + PHASE + ' Tests')     steps {       script {         println "Generate " + PHASE + " for exec in both " + DELIVERY + " & " + BASE + "  ${env.ENV} environments"          :       }     }   }   // Exec parallel $PHASE tests   : } }

Add Comment

[Luke.Lussenden@gmail.com (JIRA)]

Luke Lussenden commented on JENKINS-43820

Re: Stage name must be a string literal

I would also appreciate support for constants. My use-case involves shared library code which makes post action decisions based on the failed stage name. Re-defining the stage name in multiple places is brittle and someone could easily decide to change the display name causing code to silently fail when the stage name doesn't match what it's looking for.  Using a constant would help this problem.   Support for: static final String BUILD = "Build Stage"  For stage names would be most appreciated.

Add Comment

This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)

[madhu.shesharam@gmail.com (JIRA)]

madhu Shesharam updated an issue

Jenkins / JENKINS-43820

Stage name must be a string literal

Change By: madhu Shesharam Attachment: image-2020-03-28-00-13-53-948.png

Add Comment

[madhu.shesharam@gmail.com (JIRA)]

madhu Shesharam updated an issue

Jenkins / JENKINS-43820 Stage name must be a string literal

Change By: madhu Shesharam Attachment: image-2020-03-28-00-14-28-613.png

Add Comment

[madhu.shesharam@gmail.com (JIRA)]

madhu Shesharam commented on JENKINS-43820

Re: Stage name must be a string literal Jenkins DSL (declarative syntax)  Below should work for Dynamic State Names.   /** code placeholder **/ def buildType pipeline { agent any parameters { choice(name: 'BUILDTYPE', choices: ['ANDROID', 'IOS', 'LINUX', 'WINDOWS'], description: 'Pick Build Type') } stages { stage('Prepare') { steps { script { buildType = "${params.BUILDTYPE}" createBuilds(buildType) // Dynamic Stage Name } } } } } def createBuilds(thestage){ stage(thestage) { echo "$thestage" if (thestage.contains("ANDROID")) { echo "Build Specific to $thestage" // Do execute based on ? } } }

Add Comment

[brian.murrell@intel.com (JIRA)]

Brian J Murrell updated an issue

Jenkins / JENKINS-43820

Stage name must be a string literal

Change By: Brian J Murrell Attachment: screenshot-matrix.png

Add Comment

[brian.murrell@intel.com (JIRA)]

Brian J Murrell commented on JENKINS-43820

Re: Stage name must be a string literal This gets really, super ugly in the context of matrix. Surely you can see how not being able to substitute a variable into the stage name makes this a much less-than-useful representation of the job: I have no idea what any of those stages are without hovering over the "Matrix" text for each combination.

Add Comment

[kahmeal@gmail.com (JIRA)]

Kamil Mackow commented on JENKINS-43820

Re: Stage name must be a string literal

Just chiming in to voice my support for Brian J Murrell as I ran into the same limitation with matrix stages myself and do not see the proposed workaround as a viable one in these scenarios. Responding with "conscious design decision" and no other explanation is a cop out and, given the very valid nature of the responses here, I would challenge you to defend the statement Andrew Bayer.

Add Comment