[JIRA] (JENKINS-28178) Option to disable sandbox in CpsScmFlowDefinition
Title: Message Title Fernando Nasser commented on JENKINS-28178 Re: Option to disable sandbox in CpsScmFlowDefinition Third that. 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.162496.1430411624000.5778.1581371162198%40Atlassian.JIRA.
[JIRA] (JENKINS-49700) nested pod template in library doesn't work as documented
Title: Message Title Fernando Nasser commented on JENKINS-49700 Re: nested pod template in library doesn't work as documented Thorsten Kunz can you confirm (or not) that the change above solves your problem? 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.188638.1519319001000.13195.1563307020245%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49700) nested pod template in library doesn't work as documented
Title: Message Title Fernando Nasser assigned an issue to Thorsten Kunz Jenkins / JENKINS-49700 nested pod template in library doesn't work as documented Change By: Fernando Nasser Assignee: Thorsten Kunz 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.188638.1519319001000.13185.1563306960305%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title Fernando Nasser commented on JENKINS-44930 Re: Allow sh to return exit status, stdout and stderr all at once Norbert Lange The "command" was in a quote, but yes, we were talking about the 'sh' step. In fact we use "tee" after the '|' so we are also showing the command output in the log. I agree that the output should also go to the log. 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.183003.149756330.14644.1559089502369%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title Fernando Nasser commented on JENKINS-44930 Re: Allow sh to return exit status, stdout and stderr all at once Although I am one of the supporters for the implementation of a solution to this JIRA I have to object to a solution like: " I believe command "sh" should always return an object with all relevant output (stdout, stderr, exit_code) " Output of sysout and syserr may be too extensive, have all sort of characters, etc. We had a system that included the output as one of the fields of a JSON output and that was always causing problems, requiring retrying, etc. The workaround for this JIRA that we are using for quite some time and it is working very well is to, if output is requested, write it to a file in the WORSPACE. We do it by piping the output (sysout and/or syserr) but that should be much clear if done by the command itself. 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.183003.149756330.13657.1559053801479%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49947) unclear usage of input step in declarative pipeline
Title: Message Title Fernando Nasser commented on JENKINS-49947 Re: unclear usage of input step in declarative pipeline OK, just for the sake of people who look at this JIRA. How do we get when first, input after ? How do we get input first, when after ? 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56766) Allow preserved stashes to be used in new run of the job
Title: Message Title
Fernando Nasser created an issue
Jenkins / JENKINS-56766
Allow preserved stashes to be used in new run of the job
Issue Type:
Improvement
Assignee:
Unassigned
Components:
workflow-basic-steps-plugin
Created:
2019-03-26 18:21
Priority:
Minor
Reporter:
Fernando Nasser
Ref.: https://jenkins.io/doc/book/pipeline/running-pipelines/#preserving-stashes-for-use-with-restarted-stages Currently we can request that a stash be kept after a job finishes, even for more than one job (why? it is not clear from the text above how this would be useful. Multiple restarts perhaps?). But it is only available if we restart a stage of a job (so I guess it must have failed). At least is what the above text seems to imply and some empirical data confirms. As we are storing the stash tar balls anyway, why not make them available for the next job that starts regularly (as opposed to with a restart)? That way we could store some data to be tested on the next run and make a decision based on it. Possible use cases would be to store something like the last commitId tested so you don't run the tests again for the same code and any other things about the last run that would be useful for the next run. E.g.:
pipeline {
agent {
node {
label 'centos'
}
}
options {
preserveStashes(buildCount: 5)
}
environment {
CHANGED = 'False'
}
stages {
stage('Check for changes'){
agent {
node {
label 'rhel'
}
}
steps {
script {
def cmd = "git ls-remote https://xxx..zzz.com/mycode.git master | awk '{print \$1}' | tee last-image-build.txt.new"
echo "cmd: ${cmd}"
def newcommitid = sh (returnStdout: true, script: "${cmd}")
echo "newcommitid: ${newcommitid}"
try {
[JIRA] (JENKINS-49700) nested pod template in library doesn't work as documented
Title: Message Title
Fernando Nasser commented on JENKINS-49700
Re: nested pod template in library doesn't work as documented
Thorsten Kunz try changing this line slaveContainers.helmTemplate { to slaveContainers.helmTemplate { label -> You must use the innermost generated label in order get a node which has all the outer pods available on the node.
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.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title Fernando Nasser commented on JENKINS-44930 Re: Allow sh to return exit status, stdout and stderr all at once I'd rather keep the switches to avoid unnecessary overhead in the cases these are not necessary. 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title
Fernando Nasser commented on JENKINS-44930
Re: Allow sh to return exit status, stdout and stderr all at once
Another option: def status = sh(returnStatus: true, returnStdout: true, returnStderr: true, script: "git merge --no-edit $branches") Would return a Map, which can be seen as { 'rc': , 'stdout': , 'stderr': } A compromise would be to have both stderr and stdout together (easy to capture?) { 'rc': , 'output': } P.S.: The 'returnStderr' does not exist yet, I'll file a JIRA for it as it is useful independently.
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.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54783) Library additions to Global Variable Reference are not displayed formatted
Title: Message Title
Fernando Nasser edited a comment on JENKINS-54783
Re: Library additions to Global Variable Reference are not displayed formatted
OK, this seems to be a documentation issue.For HTML rendering this plugin must be installed: O WASP OWASP Markup Formatter Plugin ("Safe HTML" formatter) https://wiki.jenkins.io/pages/viewpage.action?pageId=71436291If you want Markdown as well, this one: https://wiki.jenkins.io/display/JENKINS/PegDown+Formatter+Plugin#PegDownFormatterPlugin-install(maybe needs to leave the option "suppress all HTML off)Can someone add a note where the documentation talks about the global variables .txt files please?Not sure how to change this issue to a "Documentation" one.
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.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54783) Library additions to Global Variable Reference are not displayed formatted
Title: Message Title
Fernando Nasser edited a comment on JENKINS-54783
Re: Library additions to Global Variable Reference are not displayed formatted
OK, this seems to be a documentation issue.For HTML rendering this plugin must be installed: O WASP Markup Formatter Plugin ("Safe HTML" formatter) https://wiki.jenkins.io/pages/viewpage.action?pageId=71436291If you want Markdown as well, this one: https://wiki.jenkins.io/display/JENKINS/PegDown+Formatter+Plugin#PegDownFormatterPlugin-install(maybe needs to leave the option "suppress all HTML off)Can someone add a note where the documentation talks about the global variables .txt files please?Not sure how to change this issue to a "Documentation" one.
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.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54783) Library additions to Global Variable Reference are not displayed formatted
Title: Message Title Fernando Nasser commented on JENKINS-54783 Re: Library additions to Global Variable Reference are not displayed formatted OK, this seems to be a documentation issue. For HTML rendering this plugin must be installed: https://wiki.jenkins.io/pages/viewpage.action?pageId=71436291 If you want Markdown as well, this one: https://wiki.jenkins.io/display/JENKINS/PegDown+Formatter+Plugin#PegDownFormatterPlugin-install (maybe needs to leave the option "suppress all HTML off) Can someone add a note where the documentation talks about the global variables .txt files please? Not sure how to change this issue to a "Documentation" one. 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54783) Library additions to Global Variable Reference are not displayed formatted
Title: Message Title Fernando Nasser created an issue Jenkins / JENKINS-54783 Library additions to Global Variable Reference are not displayed formatted Issue Type: Bug Assignee: Unassigned Components: pipeline Created: 2018-11-22 20:33 Priority: Minor Reporter: Fernando Nasser vars/myStep.txt is included correctly (after a successful build) in the Global Variables Reference. However, it doesn't matter if it has a MD format or a HTML format, it gets displayed as plain text, not rendered. Add Comment
[JIRA] (JENKINS-53670) Nested declarative pipelines
Title: Message Title Fernando Nasser commented on JENKINS-53670 Re: Nested declarative pipelines A similar use case: start several pipeline templates (only ONE level) in a loop. Suppose you have a template pipeline that builds/deploys some microservice but you have several microservices that are built/deployed in a similar way. Currently you have to build one by one. The same applies to any kind of thing you do with a template pipeline. 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-52774) Restart from Stage doesn't restore global variable
Title: Message Title
Fernando Nasser commented on JENKINS-52774
Re: Restart from Stage doesn't restore global variable
Daniel Kurzynski I saved some state in a file and if it fails and is restarted I read what I need from that file (you need set preserveStashes() I believe, I did it but I am not sure). It worked fine. For skipping steps, etc., there is a JIRA to get the isRestartedRun() and isRestartedStage() into variables that can be used outside of the when{}
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.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41519) Post stages should have well defined order
Title: Message Title Fernando Nasser commented on JENKINS-41519 Re: Post stages should have well defined order is. Many thanks for taking care of this Andrew. P.S.: Accordingly to JENKINS-41239 it has been released in Declarative 1.2.9. But this Jira says fixed-but-unreleased... 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title
Fernando Nasser edited a comment on JENKINS-44930
Re: Allow sh to return exit status, stdout and stderr all at once
Simple solution, create a returnStderr: trueAs the empty String (i.e., nothing in stderr) would mean false, it would indicate "no errors"If it is not empty, one not only knows it failed but also knows WHY it failed. {code:java} String status = sh(returnStderr: true, script: "git merge --no-edit $branches > merge_output.txt") if (status) { currentBuild.result = 'FAILED' def output = readFile('merge_output.txt').trim() slackSend channel: SLACK_CHANNEL, message: "<${env.JOB_URL}|${env.JOB_NAME}> ran into an error merging the PR branches into the ${TARGET_BRANCH} branch:\n```\n${output}\n```\n<${env.BUILD_URL}/console|See the full output>", color: 'warning', tokenCredentialId: 'slack-token' error status }sh 'rm merge_output.txt' {code}
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.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title
Fernando Nasser commented on JENKINS-44930
Re: Allow sh to return exit status, stdout and stderr all at once
Simple solution, create a returnStderr: true As the empty String (i.e., nothing in stderr) would mean false, it would indicate "no errors" If it is not empty, one not only knows it failed but also knows WHY it failed. String status = sh(returnStderr: true, script: "git merge --no-edit $branches > merge_output.txt")if (status) { currentBuild.result = 'FAILED' def output = readFile('merge_output.txt').trim() slackSend channel: SLACK_CHANNEL, message: "<${env.JOB_URL}|${env.JOB_NAME}> ran into an error merging the PR branches into the ${TARGET_BRANCH} branch:\n```\n${output}\n```\n<${env.BUILD_URL}/console|See the full output>", color: 'warning', tokenCredentialId: 'slack-token' error status} sh 'rm merge_output.txt'
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.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54378) Pipeline templates in parallel blocks are interpreted as being "nested"
Title: Message Title
Fernando Nasser created an issue
Jenkins / JENKINS-54378
Pipeline templates in parallel blocks are interpreted as being "nested"
Issue Type:
Bug
Assignee:
Andrew Bayer
Components:
pipeline-model-definition-plugin
Created:
2018-10-31 21:10
Priority:
Major
Reporter:
Fernando Nasser
I understood that having nested pipeline {} blocks was not possible. However I found out now that one cannot run pipeline {} blocks in parallel. The reason I considered this as a Bug is that these pipeline {} blocks are not "nested" (at least visibly) which is what the documentation says it is not allowed. So this should be allowed accordingly to the documentation. I marked it as Major as it takes away possibly the major use case of "pipeline templates". A common sequence of stages that achieves some X result is made into a "pipeline template" for avoiding repeating code (DNRY) and so it can be used with different parameters many times. But having to do this many times SEQUENTIALLY is most of the times impractical as it would make the pipeline execution be too long. The only workaround would be to repeat the sequence of stages in each parallel block so not using the "pipeline template". Example: I get a java.lang.IllegalStateException: Only one pipeline { ... } block can be executed in a single run. when trying to invoke it on one of the parallel blocks: (the ettPipeline is a declarative "pipeline template"; only one of it runs perfectly to completion) try { stage('Parallel Builds') { parallel ( Build1: { node { ettPipeline ( task: "${ETT_TASK}", pkg: "${ETT_PACKAGE}", scm_url: "${SCM_URL}", clentry: "${NOTE}", email: "${EMAIL}" ) }}, Build2: { node { ettPipeline ( task: "${ETT_TASK2}",
[JIRA] (JENKINS-53670) Nested declarative pipelines
Title: Message Title
Fernando Nasser commented on JENKINS-53670
Re: Nested declarative pipelines
Hi Andrew, I understood that having nested pipeline {} blocks was not possible. However I found out now that one cannot run pipeline {} blocks in parallel. So I also get a java.lang.IllegalStateException: Only one pipeline { ... } block can be executed in a single run. when trying to invoke it on one of the parallel blocks: (the ettPipeline is a declarative "pipeline template"; only one of it runs perfectly to completion) try { stage('Parallel Builds') { parallel ( Build1: { node { ettPipeline ( task: "${ETT_TASK}", pkg: "${ETT_PACKAGE}", scm_url: "${SCM_URL}", clentry: "${NOTE}", email: "${EMAIL}" ) }}, Build2: { node { ettPipeline ( task: "${ETT_TASK2}", pkg: "${ETT_PACKAGE2}", scm_url: "${SCM_URL2}", clentry: "${NOTE2}", email: "${EMAIL}" ) }}, ) } } catch(e) { currentBuild.result = "FAILED" throw e }
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.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53193) Provide currentBuild.isRestartedRun and .isRestartedStage global variables
Title: Message Title Fernando Nasser commented on JENKINS-53193 Re: Provide currentBuild.isRestartedRun and .isRestartedStage global variables isRestartedStage variable is needed as well (to match the when condition isRestartedStage() ) 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53193) Provide currentBuild.isRestartedRun and .isRestartedStage global variables
Title: Message Title Fernando Nasser updated an issue Jenkins / JENKINS-53193 Provide currentBuild.isRestartedRun and .isRestartedStage global variables Change By: Fernando Nasser Summary: Provide currentBuild.isRestartedRun and .isRestartedStage global variable variables 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53662) isRestartedRun() is not reset after a successful stage
Title: Message Title
Fernando Nasser commented on JENKINS-53662
Re: isRestartedRun() is not reset after a successful stage
Andrew Bayer In the example above, DoWork is the stage that fails and is restarted. So when { not{ isRestartedStage() } will allow it to be skipped. But in that case the RestartWork stage will not run with when { isRestartedStage() } because it was not it that failed (but DoWork). Note that I only had to use those two stages because there is no way to test inside the stage if it is a restart or the initial run. My apologies, I liked the isRestartedStage idea, but for my case above it is only useful as a variable. Basically all the when conditions are only useful to skip re-executing the step that failed (assuming you manually did what it was supposed to do), but they do not help in doing an alternative action in case of a restart. That will only be achieved with JENKINS-53193
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.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53662) isRestartedRun() is not reset after a successful stage
Title: Message Title Fernando Nasser commented on JENKINS-53662 Re: isRestartedRun() is not reset after a successful stage Good idea: the best of two worlds. But please don't forget to create a variable as well (see JENKINS-53193 for the isRestartedRun case) 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53670) Nested declarative pipelines
Title: Message Title Fernando Nasser updated an issue Jenkins / JENKINS-53670 Nested declarative pipelines Change By: Fernando Nasser Summary: Nesteddeclarative pipelines 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53670) Nested
Title: Message Title Fernando Nasser commented on JENKINS-53670 Re: Nested Note: Before someone says this, it is still useful to use the library pipeline templates from very small scripted ones that basically just provide the parameters for the specific library pipeline use. I am doing this. But to get a process pipeline that uses several standardized subprocesses in the form of library pipelines one should not be restricted to make the Jenkinsfile one a scripted one. 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53670) Nested
Title: Message Title
Fernando Nasser created an issue
Jenkins / JENKINS-53670
Nested
Issue Type:
Improvement
Assignee:
Andrew Bayer
Components:
pipeline-model-definition-plugin
Created:
2018-09-19 19:48
Priority:
Major
Reporter:
Fernando Nasser
With 1.2 a grat new feature was created, library "pipeline templates", which prevents very similar pipelines to be duplicated in many places (a maintenance nightmare, and makes it difficult to enforce organization-wide processes). However it still has some limitations (see https://issues.jenkins-ci.org/browse/JENKINS-53658) One of these, however, is really damaging. Currently one cannot use the library pipeline from a declarative pipeline (jenkinsfile for instance) and this error happens: java.lang.IllegalStateException: Only one pipeline { ... } block can be executed in a single run. This forces the use of scripted pipelines to use them, which undermines the efforts to use preferably declarative ones. It would be alright to put some limits on this. We don't need arbitrary levels of nesting. But at least being able to call a library declarative pipeline from the main declarative pipeline should be possible. Not sure if this simplifies anything in terms of implementation, but could limit use of resources (memory etc.).
[JIRA] (JENKINS-53662) isRestartedRun() is not reset after a successful stage
Title: Message Title
Fernando Nasser created an issue
Jenkins / JENKINS-53662
isRestartedRun() is not reset after a successful stage
Issue Type:
Bug
Assignee:
Andrew Bayer
Components:
pipeline-model-definition-plugin
Created:
2018-09-19 15:20
Priority:
Critical
Reporter:
Fernando Nasser
In a longer pipeline it is possible that one needs to check if a step has been restarted more than one time. Lets say steps 3 and 7 must behave different when they are restarted. If we restart the step 3 the isRestartedRun() will be true and trick step 7 in believing it has been restarted (when it was not, 3 was the one restarted). We need a way to reset this, perhaps after the first step after the restart is completed. I marked this as Critical because it really misleads the code in later stages into executing the wrong code based on misinformation. Here is one example: stages { stage('DoWork') { when { not\{ isRestartedRun() } } agent any steps { ) } } } stage('RestartWork') { when { isRestartedRun() } agent any steps { ) } } } stage('FlagTest') { when { isRestartedRun() } agent any steps { echo "isRestartedRun should be false here" } } } The last stage above does get executed, as shown in this console output: [Pipeline] echoisRestartedRun should be false here
[JIRA] (JENKINS-53658) Clarify conditions to use Declarative Pipelines in your shared libraries
Title: Message Title Fernando Nasser created an issue Jenkins / JENKINS-53658 Clarify conditions to use Declarative Pipelines in your shared libraries Issue Type: Improvement Assignee: Andrew Bayer Components: pipeline-model-definition-plugin Created: 2018-09-19 13:29 Labels: documentation Priority: Major Reporter: Fernando Nasser The documentation in https://jenkins.io/doc/book/pipeline/shared-libraries/#defining-declarative-pipelines currently says: "Only entire pipeline`s can be defined in shared libraries as of this time. This can only be done in `vars/*.groovy, and only in a call method. Only one Declarative Pipeline can be executed in a single build, and if you attempt to execute a second one, your build will fail as a result." What does it mean "Only entire pipeline`s can be defined in shared libraries"? It does not mention that the 'call' argument cannot be 'body' in "(...) and only in a call method". If you try and use body and the DELEGATE pattern the step is just not recognized (so, don't try and make it a DSL step). the part "Only one Declarative Pipeline can be executed in a single build" is a bit cryptic. It actually means that currently a pipeline cannot start another pipeline. As a consequence of (3) above, one can currently only use a library pipeline step from a non-declarative, scripted pipeline. It is not possible to use it from
[JIRA] (JENKINS-41519) Post stages should have well defined order
Title: Message Title Fernando Nasser commented on JENKINS-41519 Re: Post stages should have well defined order Thanks Stefan, not sure how I missed the JENKINS-41239 one. 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41519) Post stages should have well defined order
Title: Message Title Fernando Nasser commented on JENKINS-41519 Re: Post stages should have well defined order Caught by surprise with always not being the last one (it is sort of equivalent to the java finally which runs last, for the same cleanup reasons brought up in several JIRAs). But cleanup would work around that (/me still prefers always being last). Do we have a JIRA for the 'cleanup' addition yet? Could not find with JIRA search as the word is too common. 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53193) Provide currentBuild.isRestartedRun global variable
Title: Message Title Fernando Nasser commented on JENKINS-53193 Re: Provide currentBuild.isRestartedRun global variable Maybe this deserves a separate JIRA, but it is certainly related: In a longer pipeline it is possible that one needs to check if a step has been restarted more than one time. Lets say steps 3 and 7 must behave different when they are restarted. If we restart the step 3 the isRestartedRun() will be true and trick step 7 in believing it has been restarted (when it was not, 3 was the one restarted). We need a way to reset this, perhaps after the first step after the restart is completed. 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49947) unclear usage of input step in declarative pipeline
Title: Message Title Fernando Nasser commented on JENKINS-49947 Re: unclear usage of input step in declarative pipeline Perhaps add a 'when' configuration option to the 'input' directive? This way we could skip the input for certain cases (like for Liam's prod stage) or even have a different input for each case by playing with the right 'when' conditions. 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53193) Provide currentBuild.isRestartedRun global variable
Title: Message Title Fernando Nasser commented on JENKINS-53193 Re: Provide currentBuild.isRestartedRun global variable Fair enough. Any viable way that achieves the same result is welcome. Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-52774) Restart from Stage doesn't restore global variable
Title: Message Title Fernando Nasser commented on JENKINS-52774 Re: Restart from Stage doesn't restore global variable Wow! That would indeed solve my problem at least: I just need to save a number. For a few values this would be more than enough. And for something more elaborate the stash/unstash would be justifiable. This could perhaps provide another workaround for https://issues.jenkins-ci.org/browse/JENKINS-53193 as checking for the value of a variable can indicate if it is a restart or not. Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53193) Provide currentBuild.isRestartedRun global variable
Title: Message Title
Fernando Nasser created an issue
Jenkins / JENKINS-53193
Provide currentBuild.isRestartedRun global variable
Issue Type:
Improvement
Assignee:
Unassigned
Components:
core
Created:
2018-08-22 18:54
Priority:
Minor
Reporter:
Fernando Nasser
On a restarted stage, there is a when condition, isRestartedRun() that can be used to run or not a stage. But there isn't anything that can be used to execute a bit different on a restart than in the original run. This leads to workarounds like: stages { stage('Schedule') { when { not\{ isRestartedRun() } } agent any steps { myCommand 'isRestartedRun: false' } } stage('Restart') { when { isRestartedRun() } agent any steps { myCommand 'isRestartedRun: true' } } It would be much simpler and clearer to be able to just check for currentBuild.isRestartedRun wherever global variables are accessible
Add Comment
[JIRA] (JENKINS-52774) Restart from Stage doesn't restore global variable
Title: Message Title Fernando Nasser commented on JENKINS-52774 Re: Restart from Stage doesn't restore global variable My use case is that I need my step to work differently on restart, so I need to save a value from the previous attempt. The restart feature is wonderful and flexible but loses all data, so we have currently a mandatory process for all restarts that need some data from the previous attempt: write to file -> stash (restart) unstash -> read from file It seems to be a very common use case, so some way of preserving some data will very much enhance the experience with restarts. Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49947) unclear usage of input step in declarative pipeline
Title: Message Title
Fernando Nasser edited a comment on JENKINS-49947
Re: unclear usage of input step in declarative pipeline
Is it possible to distinguish between input \{ # manual approval of release } when \{ # the release is approved } and when \ { # the release is approved } input \{ # manual approval of release } And make the order of appearance determine what prevails? I realize that probably there is no notion of ordering for these declarations, only for stage inside stages (several elements of the same type can be ordered). Perhaps an input condition to use inside when?Or an argument to input to tell it to run after when?Of course if this is used the input value cannot be used in the when condition. I am trying to suggest something here as I have already hit the situation where I wanted them reversed, and I guess we'l have something like 50-50% of us wanting it one way or the other.
Add Comment
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)
--
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.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49947) unclear usage of input step in declarative pipeline
Title: Message Title
Fernando Nasser commented on JENKINS-49947
Re: unclear usage of input step in declarative pipeline
Is it possible to distinguish between input {
manual approval of release } when {
the release is approved } and when { # the release is approved } input {
manual approval of release }
And make the order of appearance determine what prevails?
Add Comment
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)
--
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.
For more options, visit https://groups.google.com/d/optout.
