[JIRA] (JENKINS-2111) removing a job (including multibranch/org folder branches/repos) does not remove the workspace
Title: Message Title Alexander Samoylov commented on JENKINS-2111 Re: removing a job (including multibranch/org folder branches/repos) does not remove the workspace I am using Jenkins 2.204.3 and Pipeline Plugin 2.6 and this issue is clearly reproducible for me. I delete the job with a "Delete Pipeline" button and I see all these workspaces present on every node: itself @1,2,3... @tmp Should I reopen this ticket or wait for the next version of the core or plugin? Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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.132184.1216748576000.3355.1583236204024%40Atlassian.JIRA.
[JIRA] (JENKINS-61218) Stage view for previous builds should be displayed while the build is running
Title: Message Title Alexander Samoylov created an issue Jenkins / JENKINS-61218 Stage view for previous builds should be displayed while the build is running Issue Type: Bug Assignee: Sam Van Oort Components: pipeline-stage-view-plugin Created: 2020-02-25 11:44 Environment: Jenkins 2.204.2 Pipeline Stage View Plugin: 2.13 Pipeline Stage Step: 2.3 Priority: Minor Reporter: Alexander Samoylov This issue is a consequence of another one which I described in the ticket https://issues.jenkins-ci.org/browse/JENKINS-61217. The problem is when one runs a new build the stage view is displaying only one row with the stages for the currently running build. It happens most probably because somebody programmed the plugin in such a way that stages for previous builds are removed (or just are not displayed) if they don't match stages for the last build. When the running build finishes and the plugin makes sure that the stages were not changed they are displayed again, otherwise (if they changed) only the row for the last build is displayed. Expected behaviour (what I propose): The stage view for previous builds should be untouched until the currently running build completes. The stage view for previous builds should be displayed independently on the currently running build (as a separate picture). And only when the current build completes - only then we should make a decision what to do with the previous ones (remove from the picture or not).
[JIRA] (JENKINS-61217) Stage view for previous builds should not be removed if stages change
Title: Message Title Alexander Samoylov updated an issue Jenkins / JENKINS-61217 Stage view for previous builds should not be removed if stages change Change By: Alexander Samoylov Labels: pipeline-stage-view 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.204771.1582628324000.5901.1582628402890%40Atlassian.JIRA.
[JIRA] (JENKINS-61217) Stage view for previous builds should not be removed if stages change
Title: Message Title Alexander Samoylov created an issue Jenkins / JENKINS-61217 Stage view for previous builds should not be removed if stages change Issue Type: Bug Assignee: Sam Van Oort Components: pipeline-stage-view-plugin Created: 2020-02-25 10:58 Environment: Jenkins 2.204.2 Pipeline Stage View Plugin: 2.13 Pipeline Stage Step: 2.3 Priority: Minor Reporter: Alexander Samoylov If the stages for the last build were modified (added/renamed/removed) then all stage view history for the previous builds is removed. I don't like this behavior. It is not convenient, because often I need view logs for a certain stage of a certain previous build (even if such a stage does not exist in the current build anymore). If the stages for last build don't correspond to the stages of the previous builds it is not a reason to remove the previous ones. It is still possible to display stages for each build independently. It is not a problem if a certain stage is displayed on different positions in different builds. The bigger problem is if it is not available at all like now. My proposal is to keep stages for previous builds even if they are different. That is, the stage view history should be not just a matrix, but an ordered list of ordered lists with different size. Vizualisazion? Each row can be simply independently rendered (the rows can have different length). It is possible also to "merge" it and display blank rectangles for whose builds who don't have a certain stage, but it is probably more complicated.
[JIRA] (JENKINS-41805) Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace.
Title: Message Title
Alexander Samoylov edited a comment on JENKINS-41805
Re: Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace.
[~batmat] wrote: "Not a bug by the way, more an improvement."I strongly disagree. Jenkins creates the @tmp automatically and stores there temporary files. Therefore it should be removed also automatically by Jenkins.Each tool that produces temporary data should be responsible for its removal. It is easy as ABC.Following your logic, memory leaks are also "not a bugs"...+1 for the fix (which must be trivial)Update: I confirm that the workaround dir(dir + '@tmp' ) { deleteDir() } is working. Luckily it does not create the nested @tmp@tmp. Thank you, [~vanaken].
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.178650.1486474486000.3833.1574177646038%40Atlassian.JIRA.
[JIRA] (JENKINS-41805) Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace.
Title: Message Title
Alexander Samoylov edited a comment on JENKINS-41805
Re: Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace.
[~batmat] wrote: "Not a bug by the way, more an improvement."I strongly disagree. Jenkins creates the @tmp automatically and stores there temporary files. Therefore it should be removed also automatically by Jenkins.Each tool that produces temporary data should be responsible for its removal. It is easy as ABC.Following your logic, memory leaks are also "not a bugs"...+1 for the fix (which must be trivial) Update: I confirm that the workaround dir(dir) { deleteDir() } is working. Luckily it does not create the nested @tmp@tmp. Thank you, [~vanaken].
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.178650.1486474486000.3683.1574177641848%40Atlassian.JIRA.
[JIRA] (JENKINS-41805) Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace.
Title: Message Title Alexander Samoylov commented on JENKINS-41805 Re: Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace. Baptiste Mathus wrote: "Not a bug by the way, more an improvement." I strongly disagree. Jenkins creates the @tmp automatically and stores there temporary files. Therefore it should be removed also automatically by Jenkins. Each tool that produces temporary data should be responsible for its removal. It is easy as ABC. Following your logic, memory leaks are also "not a bugs"... +1 for the fix (which must be trivial) 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.178650.1486474486000.3679.1574176323618%40Atlassian.JIRA.
[JIRA] (JENKINS-59871) env hashmap randomly mixes values of two parallel nodes
Title: Message Title
Alexander Samoylov updated an issue
Jenkins / JENKINS-59871
env hashmap randomly mixes values of two parallel nodes
Change By:
Alexander Samoylov
Please, look at this simple pipeline script:{code:java}def build(label) {// Set env globally (for all stages) on the current nodeenv.MYENVVAR = env.WORKSPACE// Printout outside of stageprint('WORKSPACE 0=' + env.WORKSPACE)print('MYENVVAR 0=' + env.MYENVVAR)stage ('Stage 1' + label) { // Printout in a stageprint('WORKSPACE 1=' + env.WORKSPACE)print('MYENVVAR 1=' + env.MYENVVAR)}}// Mainparallel('Unix' : {node ('build-linux') {build('Unix')}},'Windows' : {node ('build-win') {build('Windows')}}){code}This results to this output:{code:java}Running on build-linux in /home/build/jenkins/workspace/pipeline_bug_parallel_env_mixed_upRunning on build-win in c:\build\jenkins\pipeline_bug_parallel_env_mixed_up[Unix] WORKSPACE 0=/home/build/jenkins/workspace/pipeline_bug_parallel_env_mixed_up[Unix] MYENVVAR 0=/home/build/jenkins/workspace/pipeline_bug_parallel_env_mixed_up [Windows] WORKSPACE 0=c:\build\jenkins\pipeline_bug_parallel_env_mixed_up[Windows] MYENVVAR 0=c:\build\jenkins\pipeline_bug_parallel_env_mixed_up[Unix] WORKSPACE 1=/home/build/jenkins/workspace/pipeline_bug_parallel_env_mixed_up*[Unix] MYENVVAR 1=c:\build\jenkins\pipeline_bug_parallel_env_mixed_up* // BUG !![Windows] WORKSPACE 1=c:\build\jenkins\pipeline_bug_parallel_env_mixed_up[Windows] MYENVVAR 1=c:\build\jenkins\pipeline_bug_parallel_env_mixed_up{code}So the bug is that the env.MYENVVAR inside the [Unix] parallel branch on Unix node somehow takes value of the [Windows] parallel branch.Expected result: env.MYENVVAR = env.WORKSPACE before all stages should have assigned env.MYENVVAR for all further stages, because it was done outside the stage, that is globally for the node.There is a workaround. If I change the pipeline script by adding withEnv{} this way it works:{code:java}def build(label) {withEnv([ "MYENVVAR=" + env.WORKSPACE ]) { // WORKAROUND// Global//env.MYENVVAR = env.WORKSPACEprint('WORKSPACE 0=' + env.WORKSPACE)print('MYENVVAR 0=' + env.MYENVVAR)stage ('Stage 1' + label) {print('WORKSPACE 1=' + env.WORKSPACE)print('MYENVVAR 1=' + env.MYENVVAR)}}}{code}I don't know if my example is supposed to be supported, but if not then please fix it so that the null value is assigned. If the variable in one node {} takes value from another parallel node {} in a random way that seems to be really wrong.
[JIRA] (JENKINS-59871) env hashmap randomly mixes values of two parallel nodes
Title: Message Title
Alexander Samoylov created an issue
Jenkins / JENKINS-59871
env hashmap randomly mixes values of two parallel nodes
Issue Type:
Bug
Assignee:
Unassigned
Components:
pipeline
Created:
2019-10-21 14:36
Environment:
Labels:
pipeline pipeline-environment
Priority:
Major
Reporter:
Alexander Samoylov
Please, look at this simple pipeline script:
def build(label) {
// Set env globally (for all stages) on the current node
env.MYENVVAR = env.WORKSPACE
// Printout outside of stage
print('WORKSPACE 0=' + env.WORKSPACE)
print('MYENVVAR 0=' + env.MYENVVAR)
stage ('Stage 1' + label) { // Printout in a stage
print('WORKSPACE 1=' + env.WORKSPACE)
print('MYENVVAR 1=' + env.MYENVVAR)
}
}
// Main
parallel(
'Unix' : {
node ('build-linux') {
build('Unix')
}
},
'Windows' : {
node ('build-win') {
build('Windows')
}
}
)
This results to this output:
Running on build-linux in /home/build/jenkins/workspace/pipeline_bug_parallel_env_mixed_up
Running on build-win in
[JIRA] (JENKINS-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title
Alexander Samoylov edited a comment on JENKINS-44930
Re: Allow sh to return exit status, stdout and stderr all at once
Using a temp file is an ugly workaround which has at least these obvious disadvantages:1. You never have 100% guarantee that you don't break parallelism. Every time you introduce one more parallel "axe" (such as release/debug conf, branch, os whatever) you must take care that the temp file has the corresponding suffix.2. This method won't work in some cases if a command already contains output redirection. For example, on Linux this works: rm 123 > temp.txt 2>&1. I am not sure if we can do the same on Windows. There may be more complex cases with tricky double/single quote combinations and multiple output redirections, of a command which consists of several commands, semicolon separated. At the end we always loose generality and platform-independency if we use a temp file.3. You must remove the temp file after the command execution, but how do you do it on the node if the pipeline stuff is executed on master? You cannot use Java method File.createTempFile() for this, because it creates the temp file on master. It means that the code which generates the file name must run on master and then you pass this name to the "sh" or "bat" when you remove it. Distinguishing to "sh" and "bat" is also losing of platform-independency by the way.My current solution with which tried looks like this:{code:java}def getOSPathSep() {if (isUnix()) {return '/'} else { return '\\'}}def getTempDirOnNode() {if (isUnix()) {return env.TMPDIR != null ? env.TMPDIR : '/tmp'} else { return env.TEMP}}/* May not work if "cmd" already contains output redirection or more complex shell syntax. */def runCmdOnNodeSavingExitCodeAndStdout(cmd) {def rc = 0def stdout = nulldef tempFileName = 'runCmdOnNodeSavingExitCodeAndStdout_' + UUID.randomUUID() + '.txt'def tempFilePath = getTempDirNode() + getOSPathSep() + tempFileNamedef tempFileHandle = new File(tempFilePath)print("Using temp file: " + tempFilePath)if (isUnix()) {rc = sh(script: cmd + ' > ' + tempFilePath, returnStatus: true)} else {rc = bat(script: cmd + ' > ' + tempFilePath, returnStatus: true);}stdout = readFile(tempFilePath).trim()// Delete temporary file from the nodeif (isUnix()) {sh(script: 'rm -f ' + tempFilePath, returnStatus: true)} else {bat(script: 'del /q ' + tempFilePath, returnStatus: true);}return [ rc, stdout ]}{code}This workaround looks super ugly and of course I would want just say response = sh(cmd); response.getStatus() etc. without the tones of lines.I vote +1 for this feature. It is such a basic thing that I am surprised what else can be discussed here. just must be.If pipeline maintainers refuse to implement it we will probably need to write a plugin. I tried to implement a Java function which executes another arbitrary Java code of the given node, but it does not work directly from the pipeline script due to another limitation (see [Pipeline scripts fails to call Java code on slave: Failed to deserialize the Callable object|https://issues.jenkins-ci.org/browse/JENKINS-59778], however from a plugin it must work. But I still hope this feature will be implemented, because it is in high demand and I don't see any reason to not have it.
[JIRA] (JENKINS-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title
Alexander Samoylov edited a comment on JENKINS-44930
Re: Allow sh to return exit status, stdout and stderr all at once
Using a temp file is an ugly workaround which has at least these obvious disadvantages:1. You never have 100% guarantee that you don't break parallelism. Every time you introduce one more parallel "axe" (such as release/debug conf, branch, os whatever) you must take care that the temp file has the corresponding suffix.2. This method won't work in some cases if a command already contains output redirection. For example, on Linux this works: rm 123 > temp.txt 2>&1. I am not sure if we can do the same on Windows. There may be more complex cases with tricky double/single quote combinations and multiple output redirections, of a command which consists of several commands, semicolon separated. At the end we always loose generality and platform-independency if we use a temp file.3. You must remove the temp file after the command execution, but how do you do it on the node if the pipeline stuff is executed on master? You cannot use Java method File.createTempFile() for this, because it creates the temp file on master. It means that the code which generates the file name must run on master and then you pass this name to the "sh" or "bat" when you remove it. Distinguishing to "sh" and "bat" is also losing of platform-independency by the way.My current solution with which tried looks like this:{code:java}def getTempDirOnNode() {if (isUnix()) {return env.TMPDIR != null ? env.TMPDIR : '/tmp'} else { return env.TEMP}}/* May not work if "cmd" already contains output redirection or more complex shell syntax. */def runCmdOnNodeSavingExitCodeAndStdout(cmd) {def rc = 0def stdout = null print("Using temp directory: " + getTempDirOnNode()) def tempFileName = 'runCmdOnNodeSavingExitCodeAndStdout_' + UUID.randomUUID() + '.txt'def tempFilePath = getTempDirNode() + getOSPathSep() + tempFileNamedef tempFileHandle = new File(tempFilePath)print("Using temp file: " + tempFilePath)if (isUnix()) {rc = sh(script: cmd + ' > ' + tempFilePath, returnStatus: true)} else {rc = bat(script: cmd + ' > ' + tempFilePath, returnStatus: true);}stdout = readFile(tempFilePath).trim()// Delete temporary file from the nodeif (isUnix()) {sh(script: 'rm -f ' + tempFilePath, returnStatus: true)} else {bat(script: 'del /q ' + tempFilePath, returnStatus: true);}return [ rc, stdout ]}{code}This workaround looks super ugly and of course I would want just say response = sh(cmd); response.getStatus() etc. without the tones of lines.I vote +1 for this feature. It is such a basic thing that I am surprised what else can be discussed here. just must be.If pipeline maintainers refuse to implement it we will probably need to write a plugin. I tried to implement a Java function which executes another arbitrary Java code of the given node, but it does not work directly from the pipeline script due to another limitation (see [Pipeline scripts fails to call Java code on slave: Failed to deserialize the Callable object|https://issues.jenkins-ci.org/browse/JENKINS-59778], however from a plugin it must work. But I still hope this feature will be implemented, because it is in high demand and I don't see any reason to not have it.
[JIRA] (JENKINS-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title
Alexander Samoylov commented on JENKINS-44930
Re: Allow sh to return exit status, stdout and stderr all at once
Using a temp file is an ugly workaround which has at least these obvious disadvantages: 1. You never have 100% guarantee that you don't break parallelism. Every time you introduce one more parallel "axe" (such as release/debug conf, branch, os whatever) you must take care that the temp file has the corresponding suffix. 2. This method won't work in some cases if a command already contains output redirection. For example, on Linux this works: rm 123 > temp.txt 2>&1. I am not sure if we can do the same on Windows. There may be more complex cases with tricky double/single quote combinations and multiple output redirections, of a command which consists of several commands, semicolon separated. At the end we always loose generality and platform-independency if we use a temp file. 3. You must remove the temp file after the command execution, but how do you do it on the node if the pipeline stuff is executed on master? You cannot use Java method File.createTempFile() for this, because it creates the temp file on master. It means that the code which generates the file name must run on master and then you pass this name to the "sh" or "bat" when you remove it. Distinguishing to "sh" and "bat" is also losing of platform-independency by the way. My current solution with which tried looks like this:
def getTempDirOnNode() {
if (isUnix()) {
return env.TMPDIR != null ? env.TMPDIR : '/tmp'
} else {
return env.TEMP
}
}
/* May not work if "cmd" already contains output redirection or more complex shell syntax. */
def runCmdOnNodeSavingExitCodeAndStdout(cmd) {
def rc = 0
def stdout = null
print("Using temp directory: " + getTempDirOnNode())
def tempFileName = 'runIgnoreExitCodeStdout_' + UUID.randomUUID() + '.txt'
def tempFilePath = getTempDirNode() + getOSPathSep() + tempFileName
def tempFileHandle = new File(tempFilePath)
print("Using temp file: " + tempFilePath)
if (isUnix()) {
rc = sh(script: cmd + ' > ' + tempFilePath, returnStatus: true)
} else {
rc = bat(script: cmd + ' > ' + tempFilePath, returnStatus: true);
}
stdout = readFile(tempFilePath).trim()
// Delete temporary file from the node
if (isUnix()) {
sh(script: 'rm -f ' + tempFilePath, returnStatus: true)
} else {
bat(script: 'del /q ' + tempFilePath, returnStatus: true);
}
return [ rc, stdout ]
}
This workaround looks super ugly and of course I would want just say response = sh(cmd); response.getStatus() etc. without the tones of lines. I vote +1 for this feature. It is such a basic thing that I am surprised what else can be discussed here. just must be. If pipeline maintainers refuse to implement it we will probably need to write a plugin. I tried to implement a Java function which executes another arbitrary Java code of the given node, but it does not work directly from the pipeline script due to another limitation (see Pipeline scripts fails to call Java code on slave: Failed to deserialize the Callable object, however from a plugin it must work. But I still hope this feature will be implemented, because it is in high demand and I don't see any reason to not have it.
[JIRA] (JENKINS-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title
Alexander Samoylov edited a comment on JENKINS-44930
Re: Allow sh to return exit status, stdout and stderr all at once
Using a temp file is an ugly workaround which has at least these obvious disadvantages:1. You never have 100% guarantee that you don't break parallelism. Every time you introduce one more parallel "axe" (such as release/debug conf, branch, os whatever) you must take care that the temp file has the corresponding suffix.2. This method won't work in some cases if a command already contains output redirection. For example, on Linux this works: rm 123 > temp.txt 2>&1. I am not sure if we can do the same on Windows. There may be more complex cases with tricky double/single quote combinations and multiple output redirections, of a command which consists of several commands, semicolon separated. At the end we always loose generality and platform-independency if we use a temp file.3. You must remove the temp file after the command execution, but how do you do it on the node if the pipeline stuff is executed on master? You cannot use Java method File.createTempFile() for this, because it creates the temp file on master. It means that the code which generates the file name must run on master and then you pass this name to the "sh" or "bat" when you remove it. Distinguishing to "sh" and "bat" is also losing of platform-independency by the way.My current solution with which tried looks like this:{code:java}def getTempDirOnNode() {if (isUnix()) {return env.TMPDIR != null ? env.TMPDIR : '/tmp'} else { return env.TEMP}}/* May not work if "cmd" already contains output redirection or more complex shell syntax. */def runCmdOnNodeSavingExitCodeAndStdout(cmd) {def rc = 0def stdout = nullprint("Using temp directory: " + getTempDirOnNode())def tempFileName = ' runIgnoreExitCodeStdout_ runCmdOnNodeSavingExitCodeAndStdout_ ' + UUID.randomUUID() + '.txt'def tempFilePath = getTempDirNode() + getOSPathSep() + tempFileNamedef tempFileHandle = new File(tempFilePath)print("Using temp file: " + tempFilePath)if (isUnix()) {rc = sh(script: cmd + ' > ' + tempFilePath, returnStatus: true)} else {rc = bat(script: cmd + ' > ' + tempFilePath, returnStatus: true);}stdout = readFile(tempFilePath).trim()// Delete temporary file from the nodeif (isUnix()) {sh(script: 'rm -f ' + tempFilePath, returnStatus: true)} else {bat(script: 'del /q ' + tempFilePath, returnStatus: true);}return [ rc, stdout ]}{code}This workaround looks super ugly and of course I would want just say response = sh(cmd); response.getStatus() etc. without the tones of lines.I vote +1 for this feature. It is such a basic thing that I am surprised what else can be discussed here. just must be.If pipeline maintainers refuse to implement it we will probably need to write a plugin. I tried to implement a Java function which executes another arbitrary Java code of the given node, but it does not work directly from the pipeline script due to another limitation (see [Pipeline scripts fails to call Java code on slave: Failed to deserialize the Callable object|https://issues.jenkins-ci.org/browse/JENKINS-59778], however from a plugin it must work. But I still hope this feature will be implemented, because it is in high demand and I don't see any reason to not have it.
[JIRA] (JENKINS-59778) Pipeline script fails to call Java code on slave: Failed to deserialize the Callable object
Title: Message Title Alexander Samoylov commented on JENKINS-59778 Re: Pipeline script fails to call Java code on slave: Failed to deserialize the Callable object Well, I understand. Thank you for the clarification. You wrote also above that "The supported way to do this from Pipeline is to implement Step in a plugin, and have the step handle the interactions with remoting". Probably you know some pipeline code which implements similar thing? I tried to look for on https://github.com/jenkinsci/jenkins-scripts/tree/master/scriptler, but did not find anything useful. Could you please refer to some code snippet, of course if you know such one? 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.202502.1571054173000.8884.1571244060153%40Atlassian.JIRA.
[JIRA] (JENKINS-59778) Pipeline script fails to call Java code on slave: Failed to deserialize the Callable object
Title: Message Title Alexander Samoylov edited a comment on JENKINS-59778 Re: Pipeline script fails to call Java code on slave: Failed to deserialize the Callable object [~dnusbaum], Yes, it never worked for me. I will try to describe my use case better.I ran some Java code on slave for debugging purposes. I used the class GroovyInstallation in my pipeline script and the problem was the getExecutable(VirtualChannel channel) method of this class returned null (even after the successful installation).The method getExecutable(VirtualChannel channel) does almost the same what I wrote in my example above (see https://github.com/jenkinsci/groovy-plugin/blob/master/src/main/java/hudson/plugins/groovy/GroovyInstallation.java), that is uses Callable. I wanted to do the same directly from the pipeline code in order to run my modified version of getExecutable (with printouts etc.), but as you see it failed with those exceptions.Obviously I had a question, why Callable usage this works via the instance of GroovyInstallation, but does not work from the pipeline directly. I didn't understand what is actually the difference and that's why opened this ticket. If you think that this is not supported, why then it works fine via the instance of GroovyInstallation? 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
[JIRA] (JENKINS-59778) Pipeline script fails to call Java code on slave: Failed to deserialize the Callable object
Title: Message Title Alexander Samoylov commented on JENKINS-59778 Re: Pipeline script fails to call Java code on slave: Failed to deserialize the Callable object Devin Nusbaum, Yes, it never worked for me. I will try to describe my use case better. I ran some Java code on slave for debugging purposes. I used the class GroovyInstallation in my pipeline script and the problem was the getExecutable(VirtualChannel channel) method of this class returned null (even after the successful installation). The method getExecutable(VirtualChannel channel) does almost the same what I wrote in my example above (see https://github.com/jenkinsci/groovy-plugin/blob/master/src/main/java/hudson/plugins/groovy/GroovyInstallation.java), that is uses Callable. I wanted to do the same directly from the pipeline code in order to run my modified version of getExecutable (with printouts etc.), but as you see it failed with those exceptions. Obviously I had a question, why Callable usage this works via the instance of GroovyInstallation, but does not work from the pipeline directly. I didn't understand what is actually the difference and that's why opened this ticket. If you think that this is not supported, why then it works fine via the instance of GroovyInstallation? 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
[JIRA] (JENKINS-59778) Pipeline script fails to call Java code on slave: Failed to deserialize the Callable object
Title: Message Title
Alexander Samoylov created an issue
Jenkins / JENKINS-59778
Pipeline script fails to call Java code on slave: Failed to deserialize the Callable object
Issue Type:
Bug
Assignee:
Jeff Thompson
Components:
pipeline, remoting
Created:
2019-10-14 11:56
Environment:
Jenkins server: 2.190.1
Priority:
Minor
Reporter:
Alexander Samoylov
This is a simple pipeline script on which the issue is reproduced:
import jenkins.security.MasterToSlaveCallable;
//import hudson.remoting.Callable;
def executeJavaCodeOnNode() {
def node = Jenkins.getInstance().slaves.find({it.name == env.NODE_NAME})
def hostChannel = node.getComputer().getChannel()
def task = new MasterToSlaveCallable() {
public String call() throws IOException {
return new String("-on the node-");
}
};
hostChannel.call(task);
}
// Main
node ('linux-01') {
executeJavaCodeOnNode()
}
This simple pipeline script fails with multiple Java exceptions. I think the most relevent of them are:
java.lang.IllegalArgumentException: Unable to locate class file for class WorkflowScript$1
at hudson.remoting.Which.classFileUrl(Which.java:65)
at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch4(RemoteClassLoader.java:860)
at
[JIRA] (JENKINS-41930) manager.addShortText requires protection of characters '<' and '>'
Title: Message Title
Alexander Samoylov created an issue
Jenkins / JENKINS-41930
manager.addShortText requires protection of characters '<' and '>'
Issue Type:
Bug
Assignee:
wolfs
Components:
groovy-postbuild-plugin
Created:
2017/Feb/10 3:31 PM
Priority:
Minor
Reporter:
Alexander Samoylov
manager.addShortText(Text) displays an empty string if contains characters '<' or '>'. As a workaround, one can use: Text.replaceAll('<', '').replaceAll('>', ''). The fix, on my opinion, is to add .replaceAll('<', '').replaceAll('>', '') inside the function addShortText itself. Probably, there are other characters which are not handled properly by the function. This is also desirable to be checked.
Add Comment
[JIRA] (JENKINS-29380) Skip building on offline nodes
Title: Message Title Alexander Samoylov commented on JENKINS-29380 Re: Skip building on offline nodes I work with matrix build tightly as well and this issue is really serious, because all the build pipeline (for all matrix configurations) hangs if at least one node gets offline. On my opinion, as a user, in the best case I would expect a timeout parameter and a checkbox with 2 options: fail the build if the node is offline more than sec. skip the build if the node is offline more than sec. And if the timeout value is not set, the default behaviour is to wait infinitely as it works currently. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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] [core] (JENKINS-19465) OSX Slave hangs while being launched
Title: Message Title Alexander Samoylov commented on JENKINS-19465 Re: OSX Slave hangs while being launched I had the similar problem. An easy workaround helped me. I just updated "Host" variable with an unexisting host name and made sure that the message "This node is offline because Jenkins failed to launch the slave agent on it." was displayed by Jenkins and that "See log for more details" shows the SSH error. After that I changed the configuration back and the master ran the slave successfully. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-15748) fix Executor.interrupt(ABORTED) to let Groovy script cancel a build
Title: Message Title Alexander Samoylov commented on JENKINS-15748 Re: fix Executor.interrupt(ABORTED) to let Groovy script cancel a build I use the following workaround: buildFailure(); return 0; // this terminates Groovy script immediately after the build is marked as failed Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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.
