[JIRA] (JENKINS-53095) publishHTML() doesn't work with directories named 'class'
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-53095 publishHTML() doesn't work with directories named 'class' Change By: Christian Höltje Summary: publishHTML() doesn't work with paths that contain directories named 'class' 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-52921) Impossible to make a build from bitbucket
Title: Message Title Christian Höltje closed an issue as Not A Defect Check your network. It is unable to reach bitbucket.org. Closing. Jenkins / JENKINS-52921 Impossible to make a build from bitbucket Change By: Christian Höltje Status: Open Closed Resolution: Not A Defect 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-44231) Safely pass args to sh step
Title: Message Title
Christian Höltje commented on JENKINS-44231
Re: Safely pass args to sh step
Michael Slattery That isn't sufficient for all cases, alas. It will work for pure ascii (I think). Depending on the locale, there are many other things that'll cause problems. That's why I use withEnv(){ ... } as a work around until we can pass an array to {{sh.}}
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-37817) Pipeline should be able to use hudson.plugins.git.GitSCM getBranches
Title: Message Title Christian Höltje created an issue Jenkins / JENKINS-37817 Pipeline should be able to use hudson.plugins.git.GitSCM getBranches Issue Type: Bug Assignee: Mark Waite Components: git-plugin Created: 2016/Aug/30 4:40 PM Environment: Jenkins 2.7.2 Git-Plugin: 2.5.3 Priority: Minor Reporter: Christian Höltje When trying to use scm.branches in a Jenkinsfile to perform a shallow clone: checkout([ $class: 'GitSCM', branches: scm.branches, doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations, extensions: scm.extensions + [[$class: 'CloneOption', noTags: false, reference: '', shallow: true]], submoduleCfg: [], userRemoteConfigs: scm.userRemoteConfigs ]) I get this error: org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method hudson.plugins.git.GitSCM getBranches at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:176) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor$6.reject(SandboxInterceptor.java:243) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:363) at org.kohsuke.groovy.sandbox.impl.Checker$4.call(Ch
[JIRA] (JENKINS-37817) Pipeline should be able to use hudson.plugins.git.GitSCM getBranches
Title: Message Title Christian Höltje commented on JENKINS-37817 Re: Pipeline should be able to use hudson.plugins.git.GitSCM getBranches And FYI: I'm aware that I can approve it via the script permission page; however, I feel this should just work out of the box. 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-37817) Pipeline should be able to use hudson.plugins.git.GitSCM getBranches
Title: Message Title Christian Höltje commented on JENKINS-37817 Re: Pipeline should be able to use hudson.plugins.git.GitSCM getBranches Actually, approving seems to lead down a rat-hole of having to approve a boat-load of things, which isn't acceptable. 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-37817) Pipeline should be able to use hudson.plugins.git.GitSCM getBranches
Title: Message Title
Christian Höltje commented on JENKINS-37817
Re: Pipeline should be able to use hudson.plugins.git.GitSCM getBranches
Okay, you can't access scm.extensions, scm.doGenerateSubmoduleConfigurations}, nor {{scm.userRemoteConfigs. The same org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException error each time. What's the right way to modify the SCM options, then?
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-32540) Multibranch workflow and 'scm checkout' don't allow Git clean before checkout
Title: Message Title Christian Höltje commented on JENKINS-32540 Re: Multibranch workflow and 'scm checkout' don't allow Git clean before checkout I created the bug JENKINS-37817 since you cannot pull out the values in scm to use them in checkout. 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-37817) Pipeline should be able to use hudson.plugins.git.GitSCM getBranches
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-37817 Pipeline should be able to use hudson.plugins.git.GitSCM getBranches Change By: Christian Höltje Component/s: pipeline 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-37817) Pipeline should be able to use hudson.plugins.git.GitSCM getBranches
Title: Message Title Christian Höltje commented on JENKINS-37817 Re: Pipeline should be able to use hudson.plugins.git.GitSCM getBranches Here is the list of all the methods I had to approve to get this to work: method hudson.plugins.git.GitSCM getBranches method hudson.plugins.git.GitSCM getUserRemoteConfigs method hudson.plugins.git.GitSCM isDoGenerateSubmoduleConfigurations method hudson.plugins.git.GitSCMBackwardCompatibility getExtensions staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods plus java.util.List java.lang.Iterable staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods plus java.util.List java.lang.Object 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-38053) JellyTagException on Multijob project view with Jenkins 2.7.3 LTS
Title: Message Title Christian Höltje commented on JENKINS-38053 Re: JellyTagException on Multijob project view with Jenkins 2.7.3 LTS Is this a duplicate of JENKINS-37300 ? 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-31039) Queue items are ephemeral leading to api users to lose track of builds.
Title: Message Title Christian Höltje commented on JENKINS-31039 Re: Queue items are ephemeral leading to api users to lose track of builds. If the queueItem is stored in the build, then the /queue/item/10105 api endpoint could simply redirect to the correct build once the build has started. The /queue/item/10105 endpoint could remain "alive" until the build is deleted/cleaned-up. This would be much more "RESTy" and useful for everyone wanting to track the status of triggered builds. 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-37817) Pipeline should be able to use hudson.plugins.git.GitSCM getBranches
Title: Message Title
Christian Höltje edited a comment on JENKINS-37817
Re: Pipeline should be able to use hudson.plugins.git.GitSCM getBranches
Okay, you can't access {{scm.extensions}}, {{scm.doGenerateSubmoduleConfigurations} } , nor {{scm.userRemoteConfigs}}. The same {{org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException}} error each time.What's the right way to modify the SCM options, then?
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-37817) Pipeline should be able to use hudson.plugins.git.GitSCM getBranches
Title: Message Title Christian Höltje commented on JENKINS-37817 Re: Pipeline should be able to use hudson.plugins.git.GitSCM getBranches What does that mean I put into a Jenkinsfile? I tried scm.extensions.add([$class: 'CloneOption', noTags: false, reference: '', shallow: true]) but that didn't do anything. scm itself seems to be a GitSCM object, not a GitSCMSource. And the pipeline syntax snippets generator doesn't have anything for checkout with scm, only manually specifying everything by hand, which defeats the purpose of using the Github Org Folders plugin (which provides scm for you). 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-37817) Pipeline should be able to use hudson.plugins.git.GitSCM getBranches
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-37817 Pipeline should be able to use hudson.plugins.git.GitSCM getBranches Change By: Christian Höltje Environment: Jenkins 2.7. 2 3 Git-Plugin: 2 3 . 0.0GitHub Organization Folder Plugin: 1. 5 GitHub plugin: 1 . 3 21.1 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-38111) github organization should allow 'clean before checkout' behavior
Title: Message Title Christian Höltje commented on JENKINS-38111 Re: github organization should allow 'clean before checkout' behavior In addition, I would prefer if those Additional Behaviors (scm.extensions) were available to the Jenkinsfile since some are not useful for every repository in a GitHub Org. 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-38173) docker.build() should be to work without an image name
Title: Message Title
Christian Höltje created an issue
Jenkins / JENKINS-38173
docker.build() should be to work without an image name
Issue Type:
Improvement
Assignee:
Jesse Glick
Components:
docker-workflow-plugin
Created:
2016/Sep/13 6:29 PM
Environment:
Jenkins 2.7.3 docker-commons v1.4.1 Docker Commons Plugin docker-workflow v1.8 CloudBees Docker Pipeline
Priority:
Minor
Reporter:
Christian Höltje
When building a docker image that won't be pushed (e.g. for a build environment) then I would expect I could do def image = docker.build() and then use the image to build things. I don't need an image to be tagged, and in fact it would be preferable for it not to tagged since I may have collisions otherwise. e.g. docker.build("foo") run by two concurrent jobs would, I assume, cause havoc. The work around is to assign something like {{docker.build("somename:$ {BUILD_NUMBER} ")}} but I don't even like that since the code could be forked and run in parallel... or the Jenkinsfile could be copy-and-pasted. And I can't use $BUILD_TAG because my jobs have / characters in it. I could normalize them, but now I'm building infrastructure into my Jenkinsfile to support something I don't want/need. The traceback I get when using docker.build() is:
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method groovy.lang.GroovyObject invokeMethod java.lang.String java.lang.Object (org.jenkinsci.plugins.docker.workflow.Docker build)
at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:181)
at org.jenk
[JIRA] (JENKINS-37817) checkout scm should be override to change extensions/settings
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-37817 checkout scm should be override to change extensions/settings Change By: Christian Höltje Summary: Pipeline checkout scm should be able override to use hudson.plugins.git.GitSCM getBranches change extensions/settings 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-37817) checkout scm should be override to change extensions/settings
Title: Message Title Christian Höltje reopened an issue This is still an issue. I don't have a way to work around it, short of approving everything in Jenkinsfiles, which isn't a solution. In addition, I have more use cases... I need to be able to specify I need submodules for a project. In case it wasn't clear originally, I'm using the Github Org Folder Plugin, which means I don't have a web-ui where I can add these GitSCM.extenions. I don't know what the GitSCMSource object is or how to get it. I only have the scm object, which is a GitSCM object. It seems like there should be a way to modify (some) of the GitSCM object from the Jenkinsfile (not the ref or branch or url). I would expect to be able to do something like this: scm.add_extension([$class: 'CloneOption', noTags: false, reference: '', shallow: true]); checkout scm; Though even that is painful. :-/ I'm not even sure how that would appear (or if it would appear) in the pipeline snippet generator. Jenkins / JENKINS-37817 checkout scm should be override to change extensions/settings Change By: Christian Höltje Resolution: Won't Fix Status: Resolved Reopened Assignee: Jesse Glick Add Comment
[JIRA] (JENKINS-37817) checkout scm should be able to override extensions/settings
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-37817 checkout scm should be able to override extensions/settings Change By: Christian Höltje Summary: checkout scm should be override able to change override extensions/settings 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-38111) github organization should allow 'clean before checkout' behavior
Title: Message Title
Christian Höltje commented on JENKINS-38111
Re: github organization should allow 'clean before checkout' behavior
The way GitHub Org Folder works is the first git checkout you see is the Jenkins Server (in a "sub job" or "mini job" or whatever it is called) checking out the source on the Jenkins Server (In a directory like JENKINS_HOME/workspace///@script}}) to get the Jenkinsfile. It then uses that Jenkinsfile to actually do the build. The Jenkinsfile then allocates Workspaces via node() {} commands which may-or-may-not be empty.
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-38111) github organization should allow 'clean before checkout' behavior
Title: Message Title Christian Höltje commented on JENKINS-38111 Re: github organization should allow 'clean before checkout' behavior Right. There are two issues, really... The @script checkout on the master should probably always use shallow to prevent huge checkout times. If there was another way to just get the correct Jenkinsfile (e.g. https://raw.Jenkinsfile?token=) that'd be even better. The checkout scm needs to be configurable so changes specific to a repository can be setup, such as setting "clean before checkout" or "shallow clone". Otherwise this cannot be setup due to the way the GitHub Org Folder works. The second item is what I'm concerned about here. I should file another issue on the first item. 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-38111) github organization should allow 'clean before checkout' behavior
Title: Message Title Christian Höltje commented on JENKINS-38111 Re: github organization should allow 'clean before checkout' behavior I created JENKINS-38212 to address the "getting the Jenkinsfile" story. 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-38212) We should only get the Jenkinsfile from github, not the whole repository
Title: Message Title Christian Höltje created an issue Jenkins / JENKINS-38212 We should only get the Jenkinsfile from github, not the whole repository Issue Type: Improvement Assignee: Kohsuke Kawaguchi Components: github-organization-folder-plugin Created: 2016/Sep/14 6:59 PM Environment: Jenkins 2.7.3 github-api v1.77 GitHub API Plugin github-branch-source v1.9 GitHub Branch Source Plugin github-oauth v0.24 GitHub Authentication plugin github-organization-folder v1.5 GitHub Organization Folder Plugin github v1.21.1 GitHub plugin Priority: Major Reporter: Christian Höltje As a developer, my git repository may be large. The GitHub Org Folder plugin should only fetch the Jenkinsfile, not the whole git repository. Currently, a git clone is done for every branch of every repository. For teams with a large code base (e.g. a .git directory of 1.7GiB (real example)) this can be bad: It can take a very long time. It uses a lot of disk space on the Jenkins server. Instead, I propose we use the raw file download mechanism instead: https://raw.Jenkinsfile?token= We have all the parts needed for this. We can always fall back to git clone if the github server doesn't support the raw. interface.
[JIRA] (JENKINS-38111) github organization should allow 'clean before checkout' behavior
Title: Message Title Christian Höltje commented on JENKINS-38111 Re: github organization should allow 'clean before checkout' behavior Mark Waite I tried your Jenkinsfile against our Git Hub Enterprise and it failed because it doesn't have the correct credentials. I could shoe-horn them in there someplace (not sure where, since this interface is confusing). Either way, having to write that massive amount of boiler plate when all the values are in the scm object right now is really bad UX design. 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-38111) github organization should allow 'clean before checkout' behavior
Title: Message Title Christian Höltje commented on JENKINS-38111 Re: github organization should allow 'clean before checkout' behavior Alex Dean It isn't clear what added the web-ui options would do. It would probably do both the @script and the checkout scm. Which would be better than nothing, but not allow the per-repository control that people really need. 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-38111) github organization should allow 'clean before checkout' behavior
Title: Message Title Christian Höltje commented on JENKINS-38111 Re: github organization should allow 'clean before checkout' behavior By "per repository" I guess I really meant "per branch". Specifically, control it via a Jenkinsfile. Ideally by modifying the scm object or creating a copy in a simple way (not by copying every element one by one). Some examples that I have been recently asked about: Shallow clones Altering timeouts Clean before/after checkouts Calculate Changelog against specific branch etc. 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-38111) github organization should allow 'clean before checkout' behavior
Title: Message Title Christian Höltje commented on JENKINS-38111 Re: github organization should allow 'clean before checkout' behavior They cannot be read without triggering the need for a lot of accept approvals. 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-38111) github organization should allow 'clean before checkout' behavior
Title: Message Title Christian Höltje edited a comment on JENKINS-38111 Re: github organization should allow 'clean before checkout' behavior They cannot be read without triggering the need for a lot of accept approvals. See the linked issue: JENKINS-37817 for the list the last time I tried. That list grew as of yesterday's versions of things. 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-25804) Whitelisted signature presets for Java standard APIs and Jenkins core APIs
Title: Message Title Christian Höltje commented on JENKINS-25804 Re: Whitelisted signature presets for Java standard APIs and Jenkins core APIs This ticket is a bit open-ended. What's the conditions that needed to be satisfied to mark this ticket closed? The plugin already ships with a small static whitelist. On a clean 2.7.4 Jenkins instance the "In-process Script Approval" is empty. 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-38452) imageName() drops registry prefix outside of withRegistry() block
Title: Message Title Christian Höltje commented on JENKINS-38452 Re: imageName() drops registry prefix outside of withRegistry() block Isn't this how it is supposed to work? 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-38452) imageName() drops registry prefix outside of withRegistry() block
Title: Message Title Christian Höltje commented on JENKINS-38452 Re: imageName() drops registry prefix outside of withRegistry() block But you went out of the .withRegistry() block. It wasn't there before and it isn't after the block. In fact, that code shouldn't work unless you had a def img before the withRegistry() block. Because the img variable should no longer exist outside. 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-33510) dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes
Title: Message Title
Christian Höltje commented on JENKINS-33510
Re: dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes
I was trying to figure out if it was some weird spam or what...
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-38620) Support common user stories for docker in builds
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-38620 Support common user stories for docker in builds Change By: Christian Höltje Summary: Support common user stores stories for docker in builds 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-38620) Support common user stores for docker in builds
Title: Message Title Christian Höltje created an issue Jenkins / JENKINS-38620 Support common user stores for docker in builds Issue Type: Improvement Assignee: Unassigned Components: docker-workflow-plugin, pipeline Created: 2016/Sep/30 1:45 AM Labels: usability pipeline docker Priority: Major Reporter: Christian Höltje Having been working with developers using the Pipelines and docker containers, I'm seeing several user stories evolve: As a developer, I'm trying to build my code in CI using a container, so that my software builds the same everytime. As a developer, I'm trying to build my container in CI, so that my code is properly packaged and can be safely deployed. As a developer, I'm trying to run functional/integration tests in CI using containers, so I can ensure my code will work in production. As a devops engineer, I'm running arbitrary tasks in a container, so that tasks happen at appropriate times with respect to CI builds. Some of these tasks require that the default WORKSPACE and USER is used in the container. Other tasks, like building source code, may require that /etc/passwd and /etc/group are updated with the Jenkins user and group. I would propose that we break the docker pipeline interface up into two parts: A raw wrapper around docker with some simple conveniences that won't i
[JIRA] (JENKINS-38706) Workspace directory names mangled in multibranch pipeline
Title: Message Title Christian Höltje commented on JENKINS-38706 Re: Workspace directory names mangled in multibranch pipeline Another issue are directory names that start with -. It makes using commands more difficult (e.g. du -sch * needs to be du -sch – *). 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-38706) Workspace directory names mangled in multibranch pipeline
Title: Message Title Christian Höltje commented on JENKINS-38706 Re: Workspace directory names mangled in multibranch pipeline Just trying to collect the problems as I see it: The path names are nearly useless for "humans". I'm not too upset about that on its own, since ideally Jenkins would manage everything in a smart way on its own. The path names may start with - which is a problem for various reasons. The path names are very long and may cause issues with Windows and even Linux. A lot of the old workspace cleanup methodologies no longer work (e.g. by matching the path with the job name). There are lots of shell and groovy scripts that try to check if a workspace could possibly be in use anymore and remove it if the job doesn't exist. This was already broken in pipeline builds, but it is much more obvious now. Forcing users (e.g. Jenkinsfile authors) to manage their workspace by hand seems wrong; they shouldn't be forced to use ws() and even forcing them to use deleteDir() makes me uncomfortable. node() doesn't have the same sticky properties as a regular build. So now you'll see every job on every slave because it is random. It feels like workspaces should overall be smarter... Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-38506) Invalid workspace path for pipeline jobs on jenkins master
Title: Message Title Christian Höltje resolved as Duplicate Jenkins / JENKINS-38506 Invalid workspace path for pipeline jobs on jenkins master Change By: Christian Höltje Status: Open Resolved Resolution: Duplicate 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-36416) Create Jenkinsfile in external workspace manager plugin repository
Title: Message Title
Christian Höltje updated an issue
Jenkins / JENKINS-36416
Create Jenkinsfile in external workspace manager plugin repository
Change By:
Christian Höltje
Define {{ Jenkisfile Jenkinsfile }} for https://github.com/jenkinsci/external-workspace-manager-plugin. That Pipeline file can be integrated into https://ci.jenkins.io/
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-38706) Workspace directory names mangled in multibranch pipeline
Title: Message Title Christian Höltje commented on JENKINS-38706 Re: Workspace directory names mangled in multibranch pipeline I feel like the default workspace for node() should be special and should be removed as soon as the build is finished (or shortly after). If ws() is specified then it should follow the old-style workspace rules. Otherwise the maintenance becomes hard for the various slaves, unless you're recycling them. 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-38706) Workspace directory names mangled in multibranch pipeline
Title: Message Title
Christian Höltje commented on JENKINS-38706
Re: Workspace directory names mangled in multibranch pipeline
NO! I don't want to git clone 700MB repositories for twice for every build! I also need to compile code on multiple slaves, then copy stuff around to other slaves and then package stuff up in installers. Local workspaces must not be modified in between.
I totally agree that there needs to be a solution for things like 2.7gb git repositories (we have some) and lots of downloaded dependencies. I'm just saying that the default node() behavior isn't the right place to handle this. I would assume that anyone who needs that ability would use something like the external workspace plugin to do sane caching of data or using something like node('restriction') and ws() to ensure they don't keep getting new (empty) workspaces. With the current model, if you have 10 slaves, each with 4 executors, you have the possibility of needing to clone that repository up to 40 times, with a minimum of 10 (one per slave) per node() invocation.
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-34641) Update CCtray (cc.xml) to support Jenkins2 folders
Title: Message Title Christian Höltje commented on JENKINS-34641 Re: Update CCtray (cc.xml) to support Jenkins2 folders It may be obsolete-ish, but it is really to easy to use and things like the GitHub Authorization plugin expose it without requiring username and password if you want. 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-35273) "Keep this slave on-line as much as possible" won't reconnect after ping timeout
Title: Message Title Christian Höltje created an issue Jenkins / JENKINS-35273 "Keep this slave on-line as much as possible" won't reconnect after ping timeout Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: core, ssh-slaves-plugin Created: 2016/Jun/01 4:28 PM Environment: Jenkins ver. 1.651.1 Priority: Minor Reporter: Christian Höltje I have SSH slaves that periodically reboot. When they do, Jenkins never reconnects. The help text for "Keep this slave on-line as much as possible" says: This is the default and normal setting. In this mode, Jenkins uses tries to keep the slave on-line. If Jenkins can start the slave without user assistance, it will periodically attempt to restart the slave if it is unavailable. Jenkins will not take the slave off-line. Instead, it just sits there (for days even) unless a human clicks the "Launch Agent" button. The status is "Ping response time is too long or timed out." and the log shows: ERROR: Connection terminated java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport
[JIRA] [github-organization-folder-plugin] (JENKINS-34246) Old repos aren't removed
Title: Message Title Christian Höltje commented on JENKINS-34246 Re: Old repos aren't removed Okay so: It looks like it doesn't schedule a re-scan or anything when a new repository is added. I'm not sure that is expected or not. On a manual Re-Scan it picked up the new repository with a Jenkinsfile. Again, it didn't schedule a re-scan on repository deletion. I'm not sure if that is expected or not. On a manual Re-Scan it removed the repository. So it looks like my original bug was fixed at some point. Not sure about responding to events... It'd be tricky for the adds – e.g. I could see scheduling a rescan in, say, 5 minutes (to give the user time to add a Jenkinsfile). Deletion can probably be scheduled immediately. 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] [github-organization-folder-plugin] (JENKINS-34246) Old repos aren't removed
Title: Message Title Christian Höltje commented on JENKINS-34246 Re: Old repos aren't removed Oh, and my orphan strategy was set to "Number to keep" at 0. 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] [ssh-agent-plugin] (JENKINS-35337) Finds credentials but unable to read key: null
Title: Message Title Christian Höltje created an issue Jenkins / JENKINS-35337 Finds credentials but unable to read key: null Issue Type: Bug Assignee: Unassigned Components: ssh-agent-plugin Created: 2016/Jun/03 4:23 PM Environment: Jenkins 1.651.1 SSH Agent 1.10 Priority: Major Reporter: Christian Höltje This is in a pipeline workflow... It doesn't seem to be able to read the key, despite finding the credentials. [Pipeline] sshagent [ssh-agent] Using credentials repo (Deploy artifacts to repo) [ssh-agent] Looking for ssh-agent implementation... [ssh-agent] Java/JNR ssh-agent [ssh-agent] Unable to read key: null java.lang.NullPointerException at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgent.addIdentity(JNRRemoteAgent.java:107) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:608) at hudson.remoting.RemoteIn
[JIRA] [github-branch-source-plugin] (JENKINS-34395) Support for building tags
Title: Message Title Christian Höltje commented on JENKINS-34395 Re: Support for building tags There needs to be a way to build a "release". The two obvious patterns are: Somehow tell Jenkins this should be release and have it create a tag. Have Jenkins detect that a tag was set and build it as a release (like Travis does). 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] [durable-task-plugin] (JENKINS-29877) failure when incorrect shell is configured is not clear enough to diagnose root cause.
Title: Message Title Christian Höltje commented on JENKINS-29877 Re: failure when incorrect shell is configured is not clear enough to diagnose root cause. It seems odd that this never gave us trouble until the Pipeline. I agree its a lousy idea and I'd be willing to see the Shell option removed from Manage Jenkins -> System Configuration. 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] (JENKINS-28447) CpsScmFlowDefinition does not resolve variables
Title: Message Title Christian Höltje commented on JENKINS-28447 Re: CpsScmFlowDefinition does not resolve variables So this breaks pipeline jobs using Gerrit. The Gerrit variables are not available in the "Pipeline script from SCM" section. The are not replaced, but left as $FOOBAR; example: git -c core.askpass=true fetch --tags --progress ssh://jenk...@gerrit.example.com:29418/noodles/jenkinsfile.git $GERRIT_REFSPEC It breaks other cases too. For example, in the same job above, I've set a build parameter $GERRIT_REFSPEC and it doesn't work either. 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-28447) CpsScmFlowDefinition does not resolve variables
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-28447 CpsScmFlowDefinition does not resolve variables Change By: Christian Höltje Environment: Jenins 1.613, Workflow plugin 1.6 Also: Jenkins 1.651.1, workflow-job 2.3 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-33708) Invocation of 'sh' on Windows should provide a more helpful error
Title: Message Title
Christian Höltje commented on JENKINS-33708
Re: Invocation of 'sh' on Windows should provide a more helpful error
Based on a normal FreeStyle job, I would expect `sh` to work the same. An example I would expect to work on Windows:
sh('''#!c:\path\to\bash.exe
echo "I am in bash"
''')
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-26635) Provide Groovy workflow build step
Title: Message Title Christian Höltje commented on JENKINS-26635 Re: Provide Groovy workflow build step This would still be nice to have for system groovy scripts, assuming the script approval stuff would still work. It would be handy for maintenance jobs. 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-33661) Plugin permissions not supported
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-33661 Plugin permissions not supported Change By: Christian Höltje Issue Type: Improvement Bug 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-33661) Plugin permissions not supported
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-33661 Plugin permissions not supported Change By: Christian Höltje Priority: Minor Major 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-33661) Plugin permissions not supported
Title: Message Title Christian Höltje commented on JENKINS-33661 Re: Plugin permissions not supported I ran across this today and it took a bit of tracking to figure out what was going on... A user on a team cannot use the Pipeline "Replay" feature because of this issue. It's a pretty big usability issues. 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-33661) Plugin permissions not supported
Title: Message Title Christian Höltje edited a comment on JENKINS-33661 Re: Plugin permissions not supported I ran across this today and it took a bit of tracking to figure out what was going on...A user on a team cannot use the Pipeline "Replay" feature because of this issue.It's a pretty big usability issues issue . 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-37100) PR status name shouldn't vary
Title: Message Title Christian Höltje created an issue Jenkins / JENKINS-37100 PR status name shouldn't vary Issue Type: Bug Assignee: Kirill Merkushev Components: github-plugin Created: 2016/Aug/01 6:32 PM Environment: Jenkins: 2.7.1 GitHub-Plugin: 1.20.0 Git-Plugin: 2.5.3 Priority: Major Reporter: Christian Höltje When doing a pull request the github PR page is updated with a "status" showing the progress or result of a Jenkins build. Currently, the name for the status looks something like Jenkins job PR-1. In the github api docs, they call this the "context". The problem is that the "context" changes for each PR and branch. This makes setting up protections for branches impossible. If you turn on protections for a branch and then go to https://github.com/my-org/my-project/settings/branches/my-branch and turn on "Require status checks to pass before merging" you'll be shown "Status checks found in the last week for this repository" which might include (for example): Jenkins job PR-1 Jenkins job PR-2 Jenkins job master You can't require any of these status checks because the next status check will have a context with a new (previously unseen) PR number. Instead, it should just say "Jenkins" or a customized name specified in the default branches Jenkinsfile.
[JIRA] (JENKINS-37100) GitHub status check "context" should be constant
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-37100 GitHub status check "context" should be constant Change By: Christian Höltje Summary: PR GitHub status name shouldn't vary check "context" should be constant 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-37100) GitHub status check "context" should be constant
Title: Message Title
Christian Höltje updated an issue
Jenkins / JENKINS-37100
GitHub status check "context" should be constant
Change By:
Christian Höltje
When doing a pull request , the github PR page is updated with a " status " check showing the progress or result of a Jenkins build.Currently, the name for the status looks something like {{Jenkins job PR-1}}. In the [github api docs|https://developer.github.com/v3/repos/statuses/], they call this the "context".The problem is that the "context" changes for each PR and branch. This makes setting up protections for branches impossible.If you turn on protections for a branch and then go to {{ https://github.com/my-org/my-project/settings/branches/my-branch }} and turn on "Require status checks to pass before merging" you'll be shown "Status checks found in the last week for this repository" which might include (for example):* Jenkins job PR-1* Jenkins job PR-2* Jenkins job masterYou can't require any of these status checks because the next status check will have a context with a new (previously unseen) PR number.Instead, it should just say "Jenkins" or a customized name specified in the default branches branch's {{Jenkinsfile}}.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-37100) GitHub status check "context" should be constant
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-37100 GitHub status check "context" should be constant Change By: Christian Höltje Environment: Jenkins: 2.7.1 GitHub github - Plugin: api.jpi v1.76github-branch-source.jpi v1.8. 1 github-oauth . 20 jpi v0 . 0 24 Git github - Plugin: 2 organization-folder . 5 jpi v1 .3 github.jpi v1.19.3 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-37100) GitHub status check "context" should be constant
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-37100 GitHub status check "context" should be constant Change By: Christian Höltje Environment: Jenkins: 2.7.1github-api.jpi v1.76github-branch-source.jpi v1.8.1github-oauth.jpi v0.24github-organization-folder.jpi v1. 3 4 github.jpi v1. 19 20 . 3 0 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-37100) GitHub status check "context" should be constant
Title: Message Title Christian Höltje commented on JENKINS-37100 Re: GitHub status check "context" should be constant It looks like this Jenkinsfile snippet is supposed to change the status check "context" name but it doesn't work if using the github-organization-folder plugin: properties([ [$class: 'GithubProjectProperty', displayName: 'STATICNAME', projectUrlStr: 'https://github.com//'] ]); So I guess this is a bug in the github-organization-folder plugin? 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-37100) GitHub status check "context" should be constant
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-37100 GitHub status check "context" should be constant Change By: Christian Höltje Component/s: github-organization-folder-plugin 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-37100) GitHub status check "context" should be constant
Title: Message Title
Christian Höltje commented on JENKINS-37100
Re: GitHub status check "context" should be constant
I think I found the source of the problem in the github-branch-source-plugin:...GitHubBuildStatusNotification.java:73. It seems like it should be replaced with something like:
private static void createCommitStatus(@Nonnull GHRepository repo, @Nonnull String revision, @Nonnull GHCommitState state, @Nonnull String url, @Nonnull String message, @Nonnull Job job) throws IOException {
LOGGER.log(Level.FINE, "{0}/commit/{1} {2} from {3}", new Object[] {repo.getHtmlUrl(), revision, state, url});
repo.createCommitStatus(revision, state, url, message, "Jenkins job " + job.getParent().getName());
}
I added getParent() so that the context name would become "Jenkins job " instead of "Jenkins job ".
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-37100) GitHub status check "context" should be constant
Title: Message Title Christian Höltje commented on JENKINS-37100 Re: GitHub status check "context" should be constant Ah, I found some comments on this on https://github.com/jenkinsci/github-branch-source-plugin/commit/5a98d2a885aa951087ba329acdc560bc1e6b7062 and a duplicate issue https://issues.jenkins-ci.org/browse/JENKINS-36574. 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-37100) GitHub status check "context" should be constant
Title: Message Title Christian Höltje closed an issue as Duplicate Jenkins / JENKINS-37100 GitHub status check "context" should be constant Change By: Christian Höltje Status: Open Closed Resolution: Duplicate 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-36574) Add option to choose static notification context
Title: Message Title Christian Höltje commented on JENKINS-36574 Re: Add option to choose static notification context Heh. I didn't find this when searching originally, in part because I didn't know what was causing this problem. So I filed JENKINS-37100 about this. I think Nick Jones's suggestion is the right one. I'll see if I can figure it out how to do a pull request for that. 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-36574) Add option to choose static notification context
Title: Message Title Christian Höltje commented on JENKINS-36574 Re: Add option to choose static notification context I pushed up a Pull Request that sets the context to one of: continuous-integration/jenkins/pr continuous-integration/jenkins/branch It's hacky (it looks at job.getName() to figure out if it is a PR or not) because I couldn't figure out a better way to detect if it is a PR or not. 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-36574) Add option to choose static notification context
Title: Message Title Christian Höltje commented on JENKINS-36574 Re: Add option to choose static notification context I barely know enough Java to do what I did. Ideally I would want to be able to replace the jenkins with something identifying what Jenkins. e.g. automan But that'd require understanding Jelly, etc. 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-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title Christian Höltje commented on JENKINS-34289 Re: docker.image.inside fails unexpectedly with Jenkinsfile Agreed. But it was definitely something in the change between 1.72.1 and 1.75. I should have closed it myself. Sorry. 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] [multijob-plugin] (JENKINS-31579) phaseJobs() are being skipped when there are no changes.
Title: Message Title Christian Höltje created an issue Jenkins / JENKINS-31579 phaseJobs() are being skipped when there are no changes. Issue Type: Bug Assignee: Unassigned Components: multijob-plugin Created: 16/Nov/15 8:18 PM Environment: Jenkins: 1.625.2 MultiJob-Plugin: 1.19 Labels: plugin Priority: Major Reporter: Christian Höltje With version 1.19, jobs are being skipped with the message: Job status: [gerrit-master-FooApp-Assets] subjob has no changes since last build. I expected all jobs to be built, regardless of whether there are changes or not. With version 1.18, these jobs are build built regardless of the changes in SCM with the message: Job status: [gerrit-master-FooApp-Assets] the 'build only if scm changes' feature is disabled. I tried reading through the commits to find the problem and I suspect it is commit 170e19a30b422cd445334edd29918277da298eb7 Fix
[JIRA] [multijob-plugin] (JENKINS-31580) Multijob doesn't trigger downstream job without SCM if "Build only if SCM changes" disabled
Title: Message Title Christian Höltje resolved as Duplicate This is a duplicate of JENKINS-31579 Jenkins / JENKINS-31580 Multijob doesn't trigger downstream job without SCM if "Build only if SCM changes" disabled Change By: Christian Höltje Status: Open Resolved Resolution: Duplicate 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] [github-organization-folder-plugin] (JENKINS-34246) Old repos aren't removed
Title: Message Title
Christian Höltje created an issue
Jenkins / JENKINS-34246
Old repos aren't removed
Issue Type:
Bug
Assignee:
Kohsuke Kawaguchi
Components:
github-organization-folder-plugin
Created:
2016/Apr/14 3:41 PM
Environment:
Jenkins 1.642.4 + Github Organization Folder Plugin 1.2 GitHub Enterprise in private mode.
Priority:
Minor
Reporter:
Christian Höltje
If I remove all {{Jenkinsfile}}s from a GitHub repository (all branches) then the repository is still left in the folder. The contents of the repository are empty (i.e. no branches are shown).
The same happens if I delete or transfer a repository to a another group/owner.
I expected the repository to disappear if there are no longer any {{Jenkinsfile}}s or if the repository doesn't exist.
[JIRA] [docker-workflow-plugin] (JENKINS-34288) docker pull gives "Scripts not permitted to use new" error
Title: Message Title
Christian Höltje created an issue
Jenkins / JENKINS-34288
docker pull gives "Scripts not permitted to use new" error
Issue Type:
Bug
Assignee:
Jesse Glick
Components:
docker-workflow-plugin
Created:
2016/Apr/15 8:11 PM
Environment:
Jenkins 1.651.1 CloudBees Docker Pipeline 1.4 Pipeline 2.0
Priority:
Minor
Reporter:
Christian Höltje
Given the following code in a Jenkinsfile:
{{ node('docker') { def sdk = docker.image('some-image:latest'); sdk.pull(); }
}}
I get this traceback:
{{org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use new org.jenkinsci.plugins.docker.commons.credentials.DockerRegistryEndpoint java.lang.String java.lang.String at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectNew(StaticWhitelist.java:167) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onNewInstance(SandboxInterceptor.java:116) at org.kohsuke.groovy.sandbox.impl.Checker$3.call(Checker.java:191) at org.kohsuke.groovy.sandbox.impl.Checker.checkedConstructor(Checker.java:188) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.constructorCall(SandboxInvoker.java:19) at org.jenkinsci.plugins.docker.workflow.Do
[JIRA] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title
Christian Höltje created an issue
Jenkins / JENKINS-34289
docker.image.inside fails unexpectedly with Jenkinsfile
Issue Type:
Bug
Assignee:
Jesse Glick
Components:
docker-workflow-plugin
Created:
2016/Apr/15 9:12 PM
Environment:
Jenkins 1.651.1 CloudBees Docker Pipeline 1.4 Pipeline 2.0
Priority:
Major
Reporter:
Christian Höltje
With a simple Jenkinsfile when building, at some point it'll fail for no obvious reason.
An example Jenkinsfile:
{{ def img = 'centos:7';
node('docker') { stage "pulling"; sh "docker pull $ {img}"; // workaround for JENKINS-34288 checkout scm; docker.image(img).inside { sh 'for i in $(seq 30); do sleep 1; echo $i; done'; sh 'ls -alh --color'; } } def img = 'centos:7'; node('docker') { stage "pulling"; sh "docker pull ${img}
"; // workaround for JENKINS-34288
checkout scm;
docker.image(img).inside { sh 'for i in $(seq 30); do sleep 1; echo $i; done'; sh 'ls -alh --color'; }
} }}
Partial output:
{{ [Pipeline] Run build steps inside a
[JIRA] [docker-workflow-plugin] (JENKINS-34288) docker pull gives "Scripts not permitted to use new" error
Title: Message Title
Christian Höltje updated an issue
Jenkins / JENKINS-34288
docker pull gives "Scripts not permitted to use new" error
Change By:
Christian Höltje
Given the following code in a {{Jenkinsfile}}:{{ node('docker') { def sdk = docker.image('some-image:latest'); sdk.pull();}}} I get this traceback:{{org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use new org.jenkinsci.plugins.docker.commons.credentials.DockerRegistryEndpoint java.lang.String java.lang.String at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectNew(StaticWhitelist.java:167) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onNewInstance(SandboxInterceptor.java:116) at org.kohsuke.groovy.sandbox.impl.Checker$3.call(Checker.java:191) at org.kohsuke.groovy.sandbox.impl.Checker.checkedConstructor(Checker.java:188) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.constructorCall(SandboxInvoker.java:19) at org.jenkinsci.plugins.docker.workflow.Docker$Image.toQualifiedImageName(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:96) at org.jenkinsci.plugins.docker.workflow.Docker$Image.imageName(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:100) at org.jenkinsci.plugins.docker.workflow.Docker$Image.pull(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:120) at org.jenkinsci.plugins.docker.workflow.Docker.node(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:63) at org.jenkinsci.plugins.docker.workflow.Docker$Image.pull(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:119) at WorkflowScript.run(WorkflowScript:8) at ___cps.transform___(Native Method) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:93) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79) at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21) at com.cloudbees.groovy.cps.Next.step(Next.java:58) at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:19) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:106) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30) at org.jenkinsci.plugins.workflow.cps.CpsThr
[JIRA] [docker-workflow-plugin] (JENKINS-34288) docker pull gives "Scripts not permitted to use new" error
Title: Message Title
Christian Höltje updated an issue
Jenkins / JENKINS-34288
docker pull gives "Scripts not permitted to use new" error
Change By:
Christian Höltje
Given the following code in a {{Jenkinsfile}}: { { code:java} node('docker') { def sdk = docker.image('some-image:latest'); sdk.pull();} {code } } I get this traceback: { { code:java} org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use new org.jenkinsci.plugins.docker.commons.credentials.DockerRegistryEndpoint java.lang.String java.lang.String at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectNew(StaticWhitelist.java:167) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onNewInstance(SandboxInterceptor.java:116) at org.kohsuke.groovy.sandbox.impl.Checker$3.call(Checker.java:191) at org.kohsuke.groovy.sandbox.impl.Checker.checkedConstructor(Checker.java:188) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.constructorCall(SandboxInvoker.java:19) at org.jenkinsci.plugins.docker.workflow.Docker$Image.toQualifiedImageName(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:96) at org.jenkinsci.plugins.docker.workflow.Docker$Image.imageName(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:100) at org.jenkinsci.plugins.docker.workflow.Docker$Image.pull(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:120) at org.jenkinsci.plugins.docker.workflow.Docker.node(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:63) at org.jenkinsci.plugins.docker.workflow.Docker$Image.pull(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:119) at WorkflowScript.run(WorkflowScript:8) at ___cps.transform___(Native Method) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:93) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79) at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21) at com.cloudbees.groovy.cps.Next.step(Next.java:58) at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:19) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:106) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30) at org.
[JIRA] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title
Christian Höltje updated an issue
Jenkins / JENKINS-34289
docker.image.inside fails unexpectedly with Jenkinsfile
Change By:
Christian Höltje
With a simple {{Jenkinsfile}} when building, at some point it'll fail for no obvious reason.An example {{Jenkinsfile}}:{code: groovy java }def img = 'centos:7';node('docker') { stage "pulling"; sh "docker pull ${img}"; // workaround for JENKINS-34288 checkout scm; docker.image(img).inside {sh 'for i in $(seq 30); do sleep 1; echo $i; done';sh 'ls -alh --color'; }}{code}Partial output:{noformat}[Pipeline] Run build steps inside a Docker container : Start$ docker run -t -d -u 995:993 -w /var/lib/jenkins/workspace/tron/docwhat-test-jenkinsfile/master -v /var/lib/jenkins/workspace/tron/docwhat-test-jenkinsfile/master:/var/lib/jenkins/workspace/tron/docwhat-test-jenkinsfile/master:rw -v /var/lib/jenkins/workspace/tron/docwhat-test-jenkinsfile/master@tmp:/var/lib/jenkins/workspace/tron/docwhat-test-jenkinsfile/master@tmp:rw -e -e -e -e -e -e -e -e -e -e -e -e -e -e -e -e -e -e centos:7 cat[Pipeline] withDockerContainer {[Pipeline] sh[master] Running shell script++ seq 30+ for i in '$(seq 30)'+ sleep 1[Pipeline] } //withDockerContainer$ docker stop 7fcbfd6ab39cf05257a43a774bd20b670bc39674a204fe603ee1a3162b10$ docker rm -f 7fcbfd6ab39cf05257a43a774bd20b670bc39674a204fe603ee1a3162b10[Pipeline] Run build steps inside a Docker container : End[Pipeline] } //node[Pipeline] Allocate node : End[Pipeline] End of Pipeline{noformat}
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title
Christian Höltje updated an issue
Jenkins / JENKINS-34289
docker.image.inside fails unexpectedly with Jenkinsfile
Change By:
Christian Höltje
With a simple {{Jenkinsfile}} when building, at some point it'll fail for no obvious reason.An example {{Jenkinsfile}}:{ {def img = 'centos code : 7';node('docker') { stage "pulling"; sh "docker pull ${img groovy } "; // workaround for JENKINS-34288 checkout scm; docker.image(img).inside {sh 'for i in $(seq 30); do sleep 1; echo $i; done';sh 'ls -alh --color'; }} def img = 'centos:7';node('docker') { stage "pulling"; sh "docker pull ${img}"; // workaround for JENKINS-34288 checkout scm; docker.image(img).inside {sh 'for i in $(seq 30); do sleep 1; echo $i; done';sh 'ls -alh --color'; }} {code } } Partial output:{ { noformat} [Pipeline] Run build steps inside a Docker container : Start$ docker run -t -d -u 995:993 -w /var/lib/jenkins/workspace/tron/docwhat-test-jenkinsfile/master -v /var/lib/jenkins/workspace/tron/docwhat-test-jenkinsfile/master:/var/lib/jenkins/workspace/tron/docwhat-test-jenkinsfile/master:rw -v /var/lib/jenkins/workspace/tron/docwhat-test-jenkinsfile/master@tmp:/var/lib/jenkins/workspace/tron/docwhat-test-jenkinsfile/master@tmp:rw -e -e -e -e -e -e -e -e -e -e -e -e -e -e -e -e -e -e centos:7 cat[Pipeline] withDockerContainer {[Pipeline] sh[master] Running shell script++ seq 30+ for i in '$(seq 30)'+ sleep 1[Pipeline] } //withDockerContainer$ docker stop 7fcbfd6ab39cf05257a43a774bd20b670bc39674a204fe603ee1a3162b10$ docker rm -f 7fcbfd6ab39cf05257a43a774bd20b670bc39674a204fe603ee1a3162b10[Pipeline] Run build steps inside a Docker container : End[Pipeline] } //node[Pipeline] Allocate node : End[Pipeline] End of Pipeline {noformat } }
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [docker-workflow-plugin] (JENKINS-34288) docker pull gives "Scripts not permitted to use new" error
Title: Message Title
Christian Höltje updated an issue
Jenkins / JENKINS-34288
docker pull gives "Scripts not permitted to use new" error
Change By:
Christian Höltje
Given the following code in a {{Jenkinsfile}}:{code:java}node('docker') { def sdk = docker.image('some-image:latest'); sdk.pull();}{code}I get this traceback:{ code:java noformat }org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use new org.jenkinsci.plugins.docker.commons.credentials.DockerRegistryEndpoint java.lang.String java.lang.String at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectNew(StaticWhitelist.java:167) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onNewInstance(SandboxInterceptor.java:116) at org.kohsuke.groovy.sandbox.impl.Checker$3.call(Checker.java:191) at org.kohsuke.groovy.sandbox.impl.Checker.checkedConstructor(Checker.java:188) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.constructorCall(SandboxInvoker.java:19) at org.jenkinsci.plugins.docker.workflow.Docker$Image.toQualifiedImageName(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:96) at org.jenkinsci.plugins.docker.workflow.Docker$Image.imageName(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:100) at org.jenkinsci.plugins.docker.workflow.Docker$Image.pull(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:120) at org.jenkinsci.plugins.docker.workflow.Docker.node(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:63) at org.jenkinsci.plugins.docker.workflow.Docker$Image.pull(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:119) at WorkflowScript.run(WorkflowScript:8) at ___cps.transform___(Native Method) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:93) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79) at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21) at com.cloudbees.groovy.cps.Next.step(Next.java:58) at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:19) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:106) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30) at org.jenkinsc
[JIRA] [github-organization-folder-plugin] (JENKINS-34246) Old repos aren't removed
Title: Message Title
Christian Höltje updated an issue
Jenkins / JENKINS-34246
Old repos aren't removed
Change By:
Christian Höltje
If I remove all {{Jenkinsfile}} s from a GitHub repository (all branches) then the repository is still left in the folder. The contents of the repository are empty (i.e. no branches are shown).The same happens if I delete or transfer a repository to a another group/owner.I expected the repository to disappear if there are no longer any {{Jenkinsfile}} s or if the repository doesn't exist.
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-21813) Provide better 404 pages
Title: Message Title
Christian Höltje updated an issue
Jenkins / JENKINS-21813
Provide better 404 pages
Change By:
Christian Höltje
Feature Request:Please add better 404 pages.Motivation:The default winstone 404 page is very ugly and unhelpful. Even if you use a different app server, the 404 pages are usually not pretty.In addition, if you proxy via apache or nginx you cannot override the 404s because there are pages that return 404 (such as the search results page) that would be disabled.Suggestion:Include a page that says something like: {noformat} The page you're looking for doesn't exist. The page you're looking for either doesn't exist or is not available to you. Try logging in and see if that helps. You can try searching for the page you're looking for: ___ {{noformat}}
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-21813) Provide better 404 pages
Title: Message Title
Christian Höltje updated an issue
Jenkins / JENKINS-21813
Provide better 404 pages
Change By:
Christian Höltje
Feature Request:Please add better 404 pages.Motivation:The default winstone 404 page is very ugly and unhelpful. Even if you use a different app server, the 404 pages are usually not pretty.In addition, if you proxy via apache or nginx you cannot override the 404s because there are pages that return 404 (such as the search results page) that would be disabled.Suggestion:Include a page that says something like:{noformat} The page you're looking for doesn't exist. The page you're looking for either doesn't exist or is not available to you. Try logging in and see if that helps. You can try searching for the page you're looking for: ___{{noformat}}
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-21813) Provide better 404 pages
Title: Message Title
Christian Höltje updated an issue
Jenkins / JENKINS-21813
Provide better 404 pages
Change By:
Christian Höltje
Feature Request:Please add better 404 pages.Motivation:The default winstone 404 page is very ugly and unhelpful. Even if you use a different app server, the 404 pages are usually not pretty.In addition, if you proxy via apache or nginx you cannot override the 404s because there are pages that return 404 (such as the search results page) that would be disabled.Suggestion:Include a page that says something like:{noformat} The page you're looking for doesn't exist. The page you're looking for either doesn't exist or is not available to you. Try logging in and see if that helps. You can try searching for the page you're looking for:___{ { noformat} }
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] [platformlabeler-plugin] (JENKINS-13145) platformlabeler: Labels aren't recognized in && expressions until a node is configured and saved.
Title: Message Title Christian Höltje commented on JENKINS-13145 Re: platformlabeler: Labels aren't recognized in && expressions until a node is configured and saved. I've been using this for a while, so I suspect this is fixed now... 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] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title Christian Höltje updated an issue Jenkins / JENKINS-34289 docker.image.inside fails unexpectedly with Jenkinsfile Change By: Christian Höltje Environment: Jenkins 1.651.1 CloudBees Docker Pipeline 1.4 Pipeline 2.0 Docker 1.11.0RHEL 7.2 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] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title
Christian Höltje edited a comment on JENKINS-34289
Re: docker.image.inside fails unexpectedly with Jenkinsfile
So part of the problem appears to be the {{-u 995:993}} option passed to {{docker run}}. This user doesn't exist inside the container and certain commands cause the container to just "exit" with an unsuccessful exit code.I made a simple {{Dockerfile}} that creates the user and group and it helps with some cases (e.g. {{ps -ef}} works now) but my {{for}} loop still dies on the first {{sleep 1}}.New {{Jenkinsfile}} : < { noformat > } def img = 'centos:7';node('docker') { stage "pulling"; sh "docker pull ${img}"; // workaround for JENKINS-34288 checkout scm; docker.build('fish', '.').inside {sh 'for i in $(seq 30); do sleep 1; echo $i; done';sh 'ls -alh --color'; }} < { noformat > } Dockerfile:{noformat}FROM centos:7RUN /sbin/groupadd -g 993 bgroupRUN /sbin/adduser -m -u 995 -g 993 build{noformat}
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] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title
Christian Höltje commented on JENKINS-34289
Re: docker.image.inside fails unexpectedly with Jenkinsfile
So part of the problem appears to be the -u 995:993 option passed to docker run. This user doesn't exist inside the container and certain commands cause the container to just "exit" with an unsuccessful exit code.
I made a simple Dockerfile that creates the user and group and it helps with some cases (e.g. ps -ef works now) but my for loop still dies on the first sleep 1.
New Jenkinsfile :
def img = 'centos:7';
node('docker') { stage "pulling"; sh "docker pull $ {img}
"; // workaround for JENKINS-34288
checkout scm;
docker.build('fish', '.').inside { sh 'for i in $(seq 30); do sleep 1; echo $i; done'; sh 'ls -alh --color'; }
}
Dockerfile:
FROM centos:7
RUN /sbin/groupadd -g 993 bgroup
RUN /sbin/adduser -m -u 995 -g 993 build
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] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title
Christian Höltje commented on JENKINS-34289
Re: docker.image.inside fails unexpectedly with Jenkinsfile
Looking into the logs, I see this error when it dies:
Apr 19, 2016 11:42:51 AM FINE org.jenkinsci.plugins.docker.workflow.client.DockerClient
Executing docker command docker inspect -f {{.Image}} ab2e6f4420e8f74916096a64cc5dda59739f63d5585e6d0eee23ee4ed47fd411
Apr 19, 2016 11:42:51 AM FINE org.jenkinsci.plugins.docker.workflow.WithContainerStep
execution failure container=ab2e6f4420e8f74916096a64cc5dda59739f63d5585e6d0eee23ee4ed47fd411
hudson.AbortException: script returned exit code -1
at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.check(DurableTaskStep.java:198)
at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.run(DurableTaskStep.java:150)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
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] [docker-workflow-plugin] (JENKINS-34288) docker pull gives "Scripts not permitted to use new" error
Title: Message Title Christian Höltje commented on JENKINS-34288 Re: docker pull gives "Scripts not permitted to use new" error The environment I used originally was pretty clean. I had only just installed the plugins and started playing with them. However, now that I have had the system up and have uninstalled and re-installed the plugins multiple times: it now works. I'm fairly certain I was restarting Jenkins after installing plugins, but I can't be positive. 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] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title
Christian Höltje edited a comment on JENKINS-34289
Re: docker.image.inside fails unexpectedly with Jenkinsfile
So part of the problem appears to be the {{-u 995:993}} option passed to {{docker run}}. This user doesn't exist inside the container and certain commands cause the container to just "exit" with an unsuccessful exit code.I made a simple {{Dockerfile}} that creates the user and group and it helps with some cases (e.g. {{ps -ef}} works now) but my {{for}} loop still dies on the first {{sleep 1}}.New {{Jenkinsfile}} :{noformat} def img = 'centos:7'; node('docker') { stage "pulling"; sh "docker pull ${img}"; // workaround for JENKINS-34288 checkout scm; docker.build('fish', '.').inside {sh 'for i in $(seq 30); do sleep 1; echo $i; done';sh 'ls -alh --color'; }}{noformat}Dockerfile:{noformat}FROM centos:7RUN /sbin/groupadd -g 993 bgroupRUN /sbin/adduser -m -u 995 -g 993 build{noformat} Edits:* Removed bogus steps
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] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title
Christian Höltje commented on JENKINS-34289
Re: docker.image.inside fails unexpectedly with Jenkinsfile
How about this?
node('docker') {
def img = docker.image('busybox');
img.pull();
img.inside {
sh 'for i in $(seq 30); do sleep 1; echo $i; done';
}
}
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] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title Christian Höltje commented on JENKINS-34289 Re: docker.image.inside fails unexpectedly with Jenkinsfile I'm pretty sure that the shell step isn't even executed inside the container and that AbortException is being returned from something else. If I change the step to run sleep 1 || true it still aborts with -1. 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] [docker-workflow-plugin] (JENKINS-34288) docker pull gives "Scripts not permitted to use new" error
Title: Message Title Christian Höltje commented on JENKINS-34288 Re: docker pull gives "Scripts not permitted to use new" error I cannot reproduce on a clean version of Jenkins. Maybe I had an older version of the plugin for some reason? 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] [docker-workflow-plugin] (JENKINS-34288) docker pull gives "Scripts not permitted to use new" error
Title: Message Title Christian Höltje resolved as Cannot Reproduce Jenkins / JENKINS-34288 docker pull gives "Scripts not permitted to use new" error Change By: Christian Höltje Status: Open Resolved Resolution: Cannot Reproduce 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] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title Christian Höltje commented on JENKINS-34289 Re: docker.image.inside fails unexpectedly with Jenkinsfile Interesting. At the moment I don't have slaves; I'm using master to build stuff... Jenkins is running as the non-root user jenkins and using DOCKER_HOST=tcp://127.0.0.1:2375 via configuring the master node. If I stand up a clean Jenkins running as root then my example code works. If I stand up a clean Jenkins running as a non-root user, then my example code fails on the first sleep 1. 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] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title
Christian Höltje edited a comment on JENKINS-34289
Re: docker.image.inside fails unexpectedly with Jenkinsfile
How about this?{code:java}node ('docker') {def img = docker.image('busybox');img.pull();img.inside {sh 'for i in $(seq 30); do sleep 1; echo $i; done';}}{code}
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] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title Christian Höltje commented on JENKINS-34289 Re: docker.image.inside fails unexpectedly with Jenkinsfile Here's my "setup a test jenkins script" incase I'm doing something stupid. I use this as root and as a new user jbugs. I pull the plugins from the existing "live-ish" Jenkins to speed things up and the init.groovy.d is just setting the UpdateCenter URL to "https://updates.jenkins-ci.org/stable-1.651/update-center.json" #!/bin/bash set -euo pipefail set -x if [ "$(id -u)" = 0 ]; then jenkins_port=5000 else jenkins_port=5010 fi cd rm -rf .jenkins mkdir -p .jenkins/plugins cp -avr /var/lib/jenkins/init.groovy.d/ .jenkins/init.groovy.d/ cp -avr /var/lib/jenkins/plugins/*.jpi .jenkins/plugins/ cat < .jenkins/config.xml 1.0 1 DOCKER_HOST tcp://127.0.0.1:2375 CONFIGXML exec java -jar /var/lib/jenkins/jenkins.war --httpPort="$jenkins_port" 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] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title Christian Höltje commented on JENKINS-34289 Re: docker.image.inside fails unexpectedly with Jenkinsfile If it helps, I was able to use auditd to see that execve() was called for the docker exec for the command in question and execve() returned 0 (which is not the exit code, but just says the syscall worked). So the command seems to be run by Jenkins. It just isn't getting the exit code back correctly (and gets -1 instead). Looking around, could this be related to JENKINS-25727 ? If I'm reading the code correctly, this is falling afoul of this code: https://github.com/jenkinsci/durable-task-plugin/blob/66d80d2b9761ebdb4f0d3bb7b9edb82357e33399/src/main/java/org/jenkinsci/plugins/durabletask/BourneShellScript.java#L172-L174 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] [docker-workflow-plugin] (JENKINS-34289) docker.image.inside fails unexpectedly with Jenkinsfile
Title: Message Title Christian Höltje commented on JENKINS-34289 Re: docker.image.inside fails unexpectedly with Jenkinsfile So I got some slaves up-and-running and the problem persists there. The slave.jar runs as the user "jenkins", not root. I suspect that if I ran it as root, it'd work like the master above. 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.
