[JIRA] (JENKINS-40695) Allow running Pipeline shared library functions on executor
Title: Message Title Kenneth Brooks edited a comment on JENKINS-40695 Re: Allow running Pipeline shared library functions on executor Help me understand how this scenario should work if I'm "using pipelines correctly"Background: All of this should be happening on a slave node (that isn't on the same filesystem as the master).* Run a command to checkout files (could be "checkout scm" step)* Get a handle to one of the files that was checked out and do something with the contents via a shared library in the vars/ directory.This doesn't work today as the shared library will run on the master, yet the files were checked out on the node.How else would we accomplish this functionality? This severely limits the usefulness of any java code inside the global libraries if they can't interact with anything on the nodes, does it not? We aren't asking for the whole pipeline script itself to run on a node. We are asking how to get a cps global lib to run on the node. 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] (JENKINS-40695) Allow running Pipeline shared library functions on executor
Title: Message Title Kenneth Brooks reopened an issue Help me understand how this scenario should work if I'm "using pipelines correctly" Background: All of this should be happening on a slave node (that isn't on the same filesystem as the master). Run a command to checkout files (could be "checkout scm" step) Get a handle to one of the files that was checked out and do something with the contents via a shared library in the vars/ directory. This doesn't work today as the shared library will run on the master, yet the files were checked out on the node. How else would we accomplish this functionality? This severely limits the usefulness of any java code inside the global libraries if they can't interact with anything on the nodes, does it not? Jenkins / JENKINS-40695 Allow running Pipeline shared library functions on executor Change By: Kenneth Brooks Resolution: Won't Do Status: Resolved Reopened Assignee: Jesse Glick Add Comment
[JIRA] (JENKINS-40695) Allow running Pipeline shared library functions on executor
Title: Message Title Kenneth Brooks commented on JENKINS-40695 Re: Allow running Pipeline shared library functions on executor We would like to see this as well. For example, a lot of the things that happen on a node are file based but the java/groovy code in the global libraries cannot access those files as they seem to run on master. Currently, We disable the master as a node that anything can execute on and force our pipeline scripts to specify node labels (which loads nodes from mesos). This ensures that people aren't 1) tying up the master executors 2) doing something nefarious to the jenkins configuration files from within their pipeline script. The downside of doing this is that the steps will always be running on a node other than master, yet the global libraries are only executing on master. I would be delighted to know if I'm way off base in my thinking here and there is a better approach. 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] (JENKINS-39499) There is no way to set changeSet property of shared library checkout to false
Title: Message Title
Kenneth Brooks edited a comment on JENKINS-39499
Re: There is no way to set changeSet property of shared library checkout to false
Same issue for us.We have lots of multibranch builds all using a global shared library that we are building.Every change for the library shows up in the changeset of the target app build.Also, the status of the target app build shows up against the commits of the global libraries in bitbucket. I agree with the OP suggestion of defaulting the changeset to false. Perhaps with the ability to override globally in the configs. I haven't pulled the code but I believe it is this line: https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/libs/SCMSourceRetriever.java#L90{code:java}delegate.setChangelog(true); // TODO is this desirable?{code}
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] (JENKINS-39499) There is no way to set changeSet property of shared library checkout to false
Title: Message Title Kenneth Brooks commented on JENKINS-39499 Re: There is no way to set changeSet property of shared library checkout to false Same issue for us. We have lots of multibranch builds all using a global shared library that we are building. Every change for the library shows up in the changeset of the target app build. Also, the status of the target app build shows up against the commits of the global libraries in bitbucket. I agree with the OP suggestion of defaulting the changeset to false. Perhaps with the ability to override globally in the configs. 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] (JENKINS-38317) Input step breaks out of global library
Title: Message Title
Kenneth Brooks updated an issue
Jenkins / JENKINS-38317
Input step breaks out of global library
Change By:
Kenneth Brooks
If I have global library in vars/myGlobalLibrary.groovy and inside of that I ask for an *input* step, the *input* step breaks out of the method.You'll see that the methods right after the {{def userInput = input}} are not executed.The methods inside my pipeline after the call to the global library are executed so it isn't killing the whole pipeline, just breaking out of the global method *release()*.If the call to *input* is moved back out into the pipeline itself it works just fine and captures the response in the userInput variable.Essentially I'm trying to use the global libraries to make my pipeline much shorter and in this case I'm trying to call out to _steps_ like *input* inside that global var.vars/myGlobalLibrary.groovy{code:java}@NonCPSdef release() {def userInput = input(id: 'userInput', message: 'Proceed with release?', parameters: [[$class: 'TextParameterDefinition', defaultValue: "1.0", description: 'Release Version', name: 'releaseVersion']])echo "never gets here"echo "releaseversion: " + userInput['releaseversion'] } {code}My pipeline stage:{code:java}@Library('pipelinehelper@master') _deployToProdStage()def deployToProdStage() {stage name:'PROD Deploy',concurrency: 1myGlobalLibrary.release()echo "Makes it here just fine"}{code}
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#7
[JIRA] (JENKINS-38317) Input step breaks out of global library
Title: Message Title
Kenneth Brooks created an issue
Jenkins / JENKINS-38317
Input step breaks out of global library
Issue Type:
Bug
Assignee:
Jesse Glick
Components:
workflow-cps-global-lib-plugin
Created:
2016/Sep/18 8:31 PM
Environment:
Jenkins 2.71 Pipeline: Shared Groovy Libraries 2.3
Priority:
Minor
Reporter:
Kenneth Brooks
If I have global library in vars/myGlobalLibrary.groovy and inside of that I ask for an input step, the input step breaks out of the method. You'll see that the methods right after the def userInput = input are not executed. The methods inside my pipeline after the call to the global library are executed so it isn't killing the whole pipeline, just breaking out of the global method release(). If the call to input is moved back out into the pipeline itself it works just fine and captures the response in the userInput variable. Essentially I'm trying to use the global libraries to make my pipeline much shorter and in this case I'm trying to call out to steps like input inside that global var. vars/myGlobalLibrary.groovy
@NonCPS
def release() {
def userInput = input(
id: 'userInput',
message: 'Proceed with release?',
parameters: [
[$class: 'TextParameterDefinition', defaultValue: "1.0", description: 'Release Version', name: 'releaseVersion']
])
echo "never gets here"
echo "releaseversion: " + userInput['releaseversion']
My pipeline stage:
