[JIRA] (JENKINS-43820) Stage name must be a string literal
Title: Message Title
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
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181338.1493122184000.8865.1580388361070%40Atlassian.JIRA.
[JIRA] (JENKINS-43820) Stage name must be a string literal
Title: Message Title
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
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181338.1493122184000.8186.1580301660861%40Atlassian.JIRA.
[JIRA] (JENKINS-43820) Stage name must be a string literal
Title: Message Title
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
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181338.1493122184000.8150.1580300460920%40Atlassian.JIRA.
[JIRA] (JENKINS-43820) Stage name must be a string literal
Title: Message Title
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
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181338.1493122184000.8148.1580300401836%40Atlassian.JIRA.
[JIRA] (JENKINS-43820) Stage name must be a string literal
Title: Message Title
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
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181338.1493122184000.8082.1580300341358%40Atlassian.JIRA.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title
Alan Champion edited a comment on JENKINS-37984
Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Just adding weight in the hope that this may be addressed sooner rather than later.My objective has been to breakdown the legacy Jenkins jobs to run various steps as parallel stages for efficiency, with minimal change to the core scripts (which I have parameterised to accommodate either serial/parallel execution) * DSL pipeline held in SCM (Git) consists of 632 lines * builds five legacy nested Jenkins jobs as "explicitly numbered" _Primary Stages:_ ## *Prepare Environment* called 6 7 times (8 stages: 1 serial + 5 parallel + 1 serial to merge report) ## *Generate Tests* (based on historical samples) with a conditional alternative stage on to accommodate a re-run that required recycling processed data (i.e. 2 stages) ## {color:#505f79}*Verify Clean Environment*{color} (optional) in parallel with stage 2 (5 stages: 1 serial + 2 parallel + 1 serial to merge report) ## *Exec Generated Tests* (3 stages: 2 parallel same tests on +two+ baselines) ## *Compare Results* (7 stages : 1 serial + 4 parallel + 1 serial to merge report)Currently, this amounts to 25 stages including the five overhead stages to handle the parallelisation. I have evolved to this state gradually, and only after I parallelised the 1st stage, did the "too big" problem appear. Also, I had expected to improve performance and visibility further by splitting _Primary Stage_ 4 into 10+ parallel stages. I am thinking that the best way forward may involve breaking the jobs into +three+ levels (instead of two) by promoting the five _Primary Stages_ as nested pipelines.I accept that this regression testing exercise may not be the norm for most but any advice/help would be appreciated on a pragmatic way forward.Thanks, Alan
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title
Alan Champion edited a comment on JENKINS-37984
Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Just adding weight in the hope that this may be addressed sooner rather than later.My objective has been to breakdown the legacy Jenkins jobs to run various steps as parallel stages for efficiency, with minimal change to the core scripts (which I have parameterised to accommodate either serial/parallel execution) * DSL pipeline held in SCM (Git) consists of 632 lines * builds five legacy nested Jenkins jobs as "explicitly numbered" _Primary Stages:_ ## *Prepare Environment* called 6 times (8 stages: 1 serial + 5 parallel + 1 serial to merge report) ## *Generate Tests* (based on historical samples) with a conditional alternative stage on a re-run (i.e. 2 stages) ## {color:#505f79}*Verify Clean Environment*{color} (optional) in parallel with stage 2 (5 stages: 1 serial + 2 parallel + 1 serial to merge report) ## *Exec Generated Tests* (3 stages: 2 parallel same tests on +two+ baselines) ## *Compare Results* ( 7 stages 1 serial + 4 parallel + 1 serial to merge report) Furthermore Currently , this amounts to 25 stages including the five overhead stages to handle the parallelisation. Also, I had expected to improve performance and visibility further by splitting _Primary Stag_e Stage_ 4 into 10+ parallel stages.I am thinking that the best way forward may involve breaking the jobs into +three+ levels (instead of two) by promoting the five _Primary Stages_ as nested pipelines.I accept that this regression testing exercise may not be the norm for most but any advice/help would be appreciated on a pragmatic way forward.Thanks, Alan
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Alan Champion commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script Just adding weight in the hope that this may be addressed sooner rather than later. My objective has been to breakdown the legacy Jenkins jobs to run various steps as parallel stages for efficiency, with minimal change to the core scripts (which I have parameterised to accommodate either serial/parallel execution) DSL pipeline held in SCM (Git) consists of 632 lines builds five legacy nested Jenkins jobs as "explicitly numbered" Primary Stages: Prepare Environment called 6 times (8 stages: 1 serial + 5 parallel + 1 serial to merge report) Generate Tests (based on historical samples) with a conditional alternative stage on a re-run (i.e. 2 stages) Verify Clean Environment (optional) in parallel with stage 2 (5 stages: 1 serial + 2 parallel + 1 serial to merge report) Exec Generated Tests (3 stages: 2 parallel same tests on two baselines) Compare Results (1 serial + 4 parallel + 1 serial to merge report) Furthermore, I had expected to improve performance and visibility further by splitting _Primary Stag_e 4 into 10+ parallel stages. I am thinking that the best way forward may involve breaking the jobs into three levels (instead of two) by promoting the five Primary Stages as nested pipelines. I accept that this regression testing exercise may not be the norm for most but any advice/help would be appreciated on a pragmatic way forward. Thanks, Alan Add Comment
[JIRA] (JENKINS-36089) Pipeline support for Promoted Builds Plugin
Title: Message Title Alan Champion commented on JENKINS-36089 Re: Pipeline support for Promoted Builds Plugin I am not sure if this is the feature I am after but essentially, it is a cross between CopyArtifact and what this might offer. Currently, I am publishing in htmlreports for a non-pipeline job and I want to promote that to the parent DSL pipeline. I tried CopyArtifact but it cannot see the htmlreports directory (i.e. linked from lastSuccessfulBuild). Perhaps by forcing a shared WORKSPACE is the simplest solution but generally, I wanted it to work without changing the legacy build jobs and cannot rely on the same WORKSPACE being used. Any tips for an easily maintained solution welcome. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.172050.1466438354000.1894.1572024662713%40Atlassian.JIRA.
[JIRA] (JENKINS-44869) Activity tabs Run id column should expand to fit value
Title: Message Title Alan Champion edited a comment on JENKINS-44869 Re: Activity tabs Run id column should expand to fit value Complementary to JENKINS-46657 allowing currentBuild.displayName, where the RUN column is no longer just simply #1-1000, this now needs to accommodate typical build/release names, which potentially may be prefixed by target environment and/or dynamic job status. In our system, using the MESSAGE column description as an "alternative" is inadequate, as this shows "Started by /upstream job" or "Replayed #?". So, having 30-35 chars the expectation is needed to see that RUN column shows the distinction; otherwise *full* currentBuild.displayName buildName, whatever width it is inconsistent with expectations and virtually useless needs to be . Thanks for your attention to this detail. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.182935.1497419598000.1359.1565636400606%40Atlassian.JIRA.
[JIRA] (JENKINS-46657) blue ocean currentBuild.displayName should show in RUN column in place of number
Title: Message Title Alan Champion commented on JENKINS-46657 Re: blue ocean currentBuild.displayName should show in RUN column in place of number In our system the MESSAGE column "alternative" is not a description, but simply shows something like "Started by /upstream job" or "Replayed #?". So, the expectation is that RUN column shows the full currentBuild.displayName buildName, whatever width it needs to be. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.184995.1504645322000.1345.1565636280252%40Atlassian.JIRA.
[JIRA] (JENKINS-44869) Activity tabs Run id column should expand to fit value
Title: Message Title Alan Champion commented on JENKINS-44869 Re: Activity tabs Run id column should expand to fit value Complementary to JENKINS-46657 allowing currentBuild.displayName, where the RUN column is no longer just #1-1000, this needs to accommodate typical build/release names, which potentially may be prefixed by target environment and/or dynamic job status. So, having 30-35 chars is needed to see the distinction; otherwise it is inconsistent with expectations and virtually useless. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.182935.1497419598000.1328.1565635440315%40Atlassian.JIRA.
