[JIRA] (JENKINS-38699) Confine git commands to workspace directory
Title: Message Title
Mark R edited a comment on JENKINS-38699
Re: Confine git commands to workspace directory
Looks like a good feature. We ran into this because we have a git mechanism that backs up job config.xmls, nextBuildNumber, and a few other files to git nightly. Every now and then a pipeline jobs git gets corrupted somehow (not sure how) and it picks up the git workspace at the root jobs level. This causes it to checkout git at the root jobs level and causes problems.The workaround of setting the GIT_CEILING_DIRECTORIES worked though we did find it is case sensitive (we set to home ${HOME} /jobs).
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.175097.1475592084000.4778.1585780020221%40Atlassian.JIRA.
[JIRA] (JENKINS-38699) Confine git commands to workspace directory
Title: Message Title
Mark R commented on JENKINS-38699
Re: Confine git commands to workspace directory
Yes we set it to ${HOME}/jobs. I was wondering where workspace came from.
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.175097.1475592084000.4775.1585779960142%40Atlassian.JIRA.
[JIRA] (JENKINS-38699) Confine git commands to workspace directory
Title: Message Title Mark R edited a comment on JENKINS-38699 Re: Confine git commands to workspace directory Looks like a good feature. We ran into this because we have a git mechanism that backs up job config.xmls, nextBuildNumber, and a few other files to git nightly. Every now and then a pipeline jobs git gets corrupted somehow (not sure how) and it picks up the git workspace at the root jobs level. This causes it to checkout git at the root jobs level and causes problems.The workaround of setting the GIT_CEILING_DIRECTORIES worked though we did find it is case sensitive (we set to home/jobs) . Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.175097.1475592084000.4772.1585779900175%40Atlassian.JIRA.
[JIRA] (JENKINS-38699) Confine git commands to workspace directory
Title: Message Title Mark R commented on JENKINS-38699 Re: Confine git commands to workspace directory Looks like a good feature. We ran into this because we have a git mechanism that backs up job config.xmls, nextBuildNumber, and a few other files to git nightly. Every now and then a pipeline jobs git gets corrupted somehow (not sure how) and it picks up the git workspace at the root jobs level. This causes it to checkout git at the root jobs level and causes problems. The workaround of setting the GIT_CEILING_DIRECTORIES worked though we did find it is case sensitive. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.175097.1475592084000.4344.1585757160164%40Atlassian.JIRA.
[JIRA] (JENKINS-45273) Pipeline Multibranch - Add the possibility to use a Jenkinsfile from other SCM
Title: Message Title Mark R commented on JENKINS-45273 Re: Pipeline Multibranch - Add the possibility to use a Jenkinsfile from other SCM Use case: I have a forked opensource repo that I want to make changes to but don't want to pollute with a Jenkinsfile to build with internally. The Jenkinsfile must thus be in a different repository (without playing games in git to "hide" the Jenkinsfile commit(s)). If however I put it in a different repository I loose the ability to have bitbucket trigger the job on push to automatically build branches - right now it will only detect changes from the repository that has the Jenkinsfile which really won't change. 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-49603) Configuration slicer does not work on groovy scripts - NoSuchFieldError: DESCRIPTOR
Title: Message Title Mark R created an issue Jenkins / JENKINS-49603 Configuration slicer does not work on groovy scripts - NoSuchFieldError: DESCRIPTOR Issue Type: New Feature Assignee: Mikael Gaunin Components: configurationslicing-plugin Created: 2018-02-16 14:44 Environment: Jenkins 2.7.1 Configuration Slicing Plugin 1.47 Groovy 1.24 Priority: Major Reporter: Mark R Field Groovy.DESCRIPTOR was removed in 1.16. https://github.com/jenkinsci/groovy-plugin/blob/groovy-1.15/src/main/java/hudson/plugins/groovy/Groovy.java#L136 https://github.com/jenkinsci/groovy-plugin/blob/groovy-1.16/src/main/java/hudson/plugins/groovy/Groovy.java#L136 Caused by: java.lang.NoSuchFieldError: DESCRIPTOR at configurationslicing.tools.GroovySlicer$GroovySlicerSpec.getToolInstallations(GroovySlicer.java:57) at configurationslicing.tools.AbstractToolSlicerSpec.getInstallations(AbstractToolSlicerSpec.java:109) at configurationslicing.tools.AbstractToolSlicerSpec.setValues(AbstractToolSlicerSpec.java:87) at configurationslicing.tools.AbstractToolSlicerSpec.setValues(AbstractToolSlicerSpec.java:24) at configurationslicing.UnorderedStringSlicer.transform(UnorderedStringSlicer.java:100) at configurationslicing.UnorderedStringSlicer.transform(UnorderedStringSlicer.java:6) at configurationslicing.ConfigurationSlicing$SliceExecutor.transform(ConfigurationSlicing.java:136) at configurationslicing.ConfigurationSlicing$SliceExecutor.doSliceconfigSubmit(ConfigurationSlicing.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
[JIRA] (JENKINS-49464) Store events in a queryable fasion
Title: Message Title Mark R created an issue Jenkins / JENKINS-49464 Store events in a queryable fasion Issue Type: New Feature Assignee: Unassigned Components: notification-plugin Created: 2018-02-08 19:30 Priority: Major Reporter: Mark R This is for a feature request to be able to store all events into a database (or file - configurable). Events could then be queried from the rest API. Advantages: Ability to pull events Ability to repush events that failed to push Ability to query events through the REST API Not sure if this should live in this plugin or a separate one. Feel free to discuss. Add Comment
[JIRA] (JENKINS-49464) Store events in a persistent location
Title: Message Title Mark R updated an issue Jenkins / JENKINS-49464 Store events in a persistent location Change By: Mark R Summary: Store events in a queryable fasion persistent location Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-39347) Notify Stash plugin problems after update
Title: Message Title Mark R commented on JENKINS-39347 Re: Notify Stash plugin problems after update What version? I am running 1.11.6 and the github code still has that Abstract build code. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-39347) Notify Stash plugin problems after update
Title: Message Title Mark R commented on JENKINS-39347 Re: Notify Stash plugin problems after update I am also getting this error. Has this been looked at? 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-38656) Can't build with JDK 1.6
Title: Message Title Mark R commented on JENKINS-38656 Re: Can't build with JDK 1.6 We have also hit this. It is also a blocker. We run the Jenkins master and slave nodes using java 8. However there are many builds of older applications that continue to target java 6. Since this plugin injects itself into the classpath it breaks builds that target java 6. Unfortunately 2.9 is needed for pipeline DSL support as well as bug fixes. 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-41990) Jenkins artifactory-plugin and old version of Httpclient / Httpmime
Title: Message Title Mark R commented on JENKINS-41990 Re: Jenkins artifactory-plugin and old version of Httpclient / Httpmime This can be resolved once the documentation is updated to indicate that version 2.9.0 and above requires version 2.13 of the maven-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-41277) can't upload artifacts to artifactory
Title: Message Title Mark R commented on JENKINS-41277 Re: can't upload artifacts to artifactory The documentation needs to be updated to indicate that 2.9+ requires version 2.13+ of the maven-plugin. https://issues.jenkins-ci.org/browse/JENKINS-41990 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-41990) Jenkins artifactory-plugin and old version of Httpclient / Httpmime
Title: Message Title Mark R updated an issue Jenkins / JENKINS-41990 Jenkins artifactory-plugin and old version of Httpclient / Httpmime Change By: Mark R Summary: Jenkins artifactory-plugin uses and old version of Httpclient / Httpmime 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-41990) Jenkins artifactory-plugin uses old version of Httpclient / Httpmime
Title: Message Title Mark R edited a comment on JENKINS-41990 Re: Jenkins artifactory-plugin uses old version of Httpclient / Httpmime Issue #1 should be fixed by version 2.9.0 as that upgraded httpclient and its assorted libraries. When we originally ran in to this issue we were running < 2.9.x.Issue #2 - it looks like the artifactory plugin 2.9.x + requires maven-plugin (?) 2.13 due to transitive dependency conficts (this changeset that updates the httpclient dependencies is needed: https://github.com/jenkinsci/maven-plugin/commit/8dcd6135e985a390993c726ad60b869ebb6dcd40). This is because if a version of the maven plugin < 2. 3 13 is used an old version of httpclient (4.2.5) / httpcore (4.2.4) is put on the classpath which is not compatible with some of the jfrog artifactory code. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41990) Jenkins artifactory-plugin uses old version of Httpclient / Httpmime
Title: Message Title Mark R edited a comment on JENKINS-41990 Re: Jenkins artifactory-plugin uses old version of Httpclient / Httpmime Issue #1 should be fixed by version 2.9.0 as that upgraded httpclient and its assorted libraries. When we originally ran in to this issue we were running < 2.9.x.Issue #2 - it looks like the artifactory plugin 2.9.x + requires maven-plugin 2.3+ (?) due to transitive dependency conficts (this changeset that updates the httpclient dependencies is needed: https://github.com/jenkinsci/maven-plugin/commit/8dcd6135e985a390993c726ad60b869ebb6dcd40). This is because if a version of the maven plugin < 2.3 is used an old version of httpclient (4.2.5) / httpcore (4.2.4) is put on the classpath which is not compatible with some of the jfrog artifactory code. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41990) Jenkins artifactory-plugin uses old version of Httpclient / Httpmime
Title: Message Title Mark R edited a comment on JENKINS-41990 Re: Jenkins artifactory-plugin uses old version of Httpclient / Httpmime Issue #1 should be fixed by version 2.9.0 as that upgraded httpclient and its assorted libraries. When we originally ran in to this issue we were running < 2.9.x. Issue #2 - it looks like the artifactory plugin 2.9.x + requires maven-plugin 2.3+ due to transitive dependency conficts (this changeset that updates the httpclient dependencies is needed: https://github.com/jenkinsci/maven-plugin/commit/8dcd6135e985a390993c726ad60b869ebb6dcd40). This is because if a version of the maven plugin < 2.3 is used an old version of httpclient (4.2.5) / httpcore (4.2.4) is put on the classpath which is not compatible with some of the jfrog artifactory code. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41990) Jenkins artifactory-plugin uses old version of Httpclient / Httpmime
Title: Message Title Mark R commented on JENKINS-41990 Re: Jenkins artifactory-plugin uses old version of Httpclient / Httpmime Issue #1 should be fixed by version 2.9.0 as that upgraded httpclient and its assorted libraries. Issue #2 - it looks like the artifactory plugin 2.9.x + requires maven-plugin 2.3+ due to transitive dependency conficts (this changeset that updates the httpclient dependencies is needed: https://github.com/jenkinsci/maven-plugin/commit/8dcd6135e985a390993c726ad60b869ebb6dcd40). This is because if a version of the maven plugin < 2.3 is used an old version of httpclient (4.2.5) / httpcore (4.2.4) is put on the classpath which is not compatible with some of the jfrog artifactory code. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41990) Jenkins artifactory-plugin uses old version of Httpclient / Httpmime
Title: Message Title Mark R created an issue Jenkins / JENKINS-41990 Jenkins artifactory-plugin uses old version of Httpclient / Httpmime Issue Type: Bug Assignee: Eyal Ben Moshe Components: artifactory-plugin Created: 2017/Feb/13 6:29 PM Priority: Major Reporter: Mark R It seems the artifactory plugin comes packaged with older versions of httpclient and httpmime. When using the artifactory integrations (generic, gradle) these end up getting placed at the _front _of the classpath on the node. As a result conflicts sometimes arise when build tools use different versions of these dependencies since the old version of classes are loaded. Examples: 1. Failed gradle build: Exception: Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':mytask'. at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46) at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35) at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:64) at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58) at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53) at
[JIRA] (JENKINS-25616) Support for coverage.xml generated by Android tools
Title: Message Title Mark R commented on JENKINS-25616 Re: Support for coverage.xml generated by Android tools Any progress with this? The incompatibility between the old and new jacoco exec files will require a transition period where old and new coverage results can be understood. One way to do this would be to consume XML in the Jenkins 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-33846) Restart pipeline from specific stage, after failure
Title: Message Title Mark R commented on JENKINS-33846 Re: Restart pipeline from specific stage, after failure Why won't this be implemented? 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-31464) git-client uses proxy from plugins section of jenkins
Title: Message Title Mark R commented on JENKINS-31464 Re: git-client uses proxy from plugins section of jenkins Ended up hitting this today. It took several hours to debug and come to the root cause. 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-40257) Artifactory plugin DSL generic uploader does not resolve credentialsId
Title: Message Title Mark R commented on JENKINS-40257 Re: Artifactory plugin DSL generic uploader does not resolve credentialsId This should fix it: GenericUploadExecutor: Credentials credentials = new Credentials(server.getDeployerCredentialsConfig().provideUsername(build.getParent()), server.getDeployerCredentialsConfig().providePassword(build.getParent())); 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-40257) Artifactory plugin DSL generic uploader does not resolve credentialsId
Title: Message Title
Mark R updated an issue
Jenkins / JENKINS-40257
Artifactory plugin DSL generic uploader does not resolve credentialsId
Change By:
Mark R
I am unable to get the artifactory plugin to work with a credentials ID using generic builds in a Jenkinsfile. The credentials work when using the statically configured UI. The credentials work when hard coding them in using username/password. The credentials do not work when referencing them with credentialsId.The stacktrace references GenericUploadExecutor.java line 52. This calls CredentialsConfig getUsername / getPassword which has a comment that says "This should not be used in order to retrieve credentials in the configuration - Use provideUsername, providePassword instead". I do not see where the credentialsId is resolved. Perhaps https://www.jfrog.com/jira/browse/HAP-810 missed this file.https://github.com/jenkinsci/artifactory-plugin/blob/e30d3b54a2f685d12f0ae65750b16c9d0c59c62e/src/main/java/org/jfrog/hudson/pipeline/executors/GenericUploadExecutor.javaRelevant Plugins:- Pipeline 2.3- Credentials 2.1.4- Artifactory plugin 2.8.1 Note the master instance is on Windows and the slave is on linux. DSL snippet:{code:java}// works with hard coded creds. Does not work with credentialsIddef server = Artifactory.newServer url: 'http://artifactoryinstance:8081/artifactory', credentialsId: '377a7f24-6ce8-4a3c-b363-373549650b1f'def publishSpec = """{ "files": [ { "pattern": "build/*.json", "target": "jenkins-build-local/${env.JOB_NAME}/${env.BUILD_NUMBER}/" } ]}""";print publishSpec;def buildInfo = Artifactory.newBuildInfo()server.upload(publishSpec, buildInfo)server.publishBuildInfo(buildInfo){code}The artifactory access log indicates that the jenkins plugin is attempting to use anonymous creds instead of what would of been resolved by the credentials ID:{noformat}2016-12-06 09:52:32,979 [DENIED DEPLOY] repository:path/file.json for anonymous/ipaddr.{noformat}{noformat}Stacktrace:java.io.IOException: remote file operation failed: /var/appl/jenkins/workspace/job/branch at hudson.remoting.Channel@1002c189:jknapdvh1: java.io.IOException: Failed to deploy file: HTTP response code: 401. HTTP response message: Unauthorized at hudson.FilePath.act(FilePath.java:1014) at hudson.FilePath.act(FilePath.java:996) at org.jfrog.hudson.pipeline.executors.GenericUploadExecutor.execution(GenericUploadExecutor.java:52) at org.jfrog.hudson.pipeline.steps.UploadStep$Execution.run(UploadStep.java:65) at org.jfrog.hudson.pipeline.steps.UploadStep$Execution.run(UploadStep.java:46) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousStepExecution.start(AbstractSynchronousStepExecution.java:40) at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:180) at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:124) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:117) at org.jfrog.hudson.pipeline.types.ArtifactoryServer.upload(ArtifactoryServer.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
[JIRA] (JENKINS-40257) Artifactory plugin DSL generic uploader does not resolve credentialsId
Title: Message Title
Mark R updated an issue
Jenkins / JENKINS-40257
Artifactory plugin DSL generic uploader does not resolve credentialsId
Change By:
Mark R
I am unable to get the artifactory plugin to work with a credentials ID using generic builds in a Jenkinsfile. The credentials work when using the statically configured UI. The credentials work when hard coding them in using username/password. The credentials do not work when referencing them with credentialsId.The stacktrace references GenericUploadExecutor.java line 52. This calls CredentialsConfig getUsername / getPassword which has a comment that says "This should not be used in order to retrieve credentials in the configuration - Use provideUsername, providePassword instead". I do not see where the credentialsId is resolved. Perhaps https://www.jfrog.com/jira/browse/HAP-810 missed this file.https://github.com/jenkinsci/artifactory-plugin/blob/e30d3b54a2f685d12f0ae65750b16c9d0c59c62e/src/main/java/org/jfrog/hudson/pipeline/executors/GenericUploadExecutor.javaRelevant Plugins:- Pipeline 2.3- Credentials 2.1.4- Artifactory plugin 2.8.1DSL snippet:{code:java}// works with hard coded creds. Does not work with credentialsIddef server = Artifactory.newServer url: 'http://artifactoryinstance:8081/artifactory', credentialsId: '377a7f24-6ce8-4a3c-b363-373549650b1f'def publishSpec = """{ "files": [ { "pattern": "build/*.json", "target": "jenkins-build-local/${env.JOB_NAME}/${env.BUILD_NUMBER}/" } ]}""";print publishSpec;def buildInfo = Artifactory.newBuildInfo()server.upload(publishSpec, buildInfo)server.publishBuildInfo(buildInfo){code}The artifactory access log indicates that the jenkins plugin is attempting to use anonymous creds instead of what would of been resolved by the credentials ID :{noformat}2016-12-06 09:52:32,979 [DENIED DEPLOY] repository:path/file.json for anonymous/ipaddr.{noformat}{noformat}Stacktrace:java.io.IOException: remote file operation failed: /var/appl/jenkins/workspace/job/branch at hudson.remoting.Channel@1002c189:jknapdvh1: java.io.IOException: Failed to deploy file: HTTP response code: 401. HTTP response message: Unauthorized at hudson.FilePath.act(FilePath.java:1014) at hudson.FilePath.act(FilePath.java:996) at org.jfrog.hudson.pipeline.executors.GenericUploadExecutor.execution(GenericUploadExecutor.java:52) at org.jfrog.hudson.pipeline.steps.UploadStep$Execution.run(UploadStep.java:65) at org.jfrog.hudson.pipeline.steps.UploadStep$Execution.run(UploadStep.java:46) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousStepExecution.start(AbstractSynchronousStepExecution.java:40) at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:180) at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:124) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:117) at org.jfrog.hudson.pipeline.types.ArtifactoryServer.upload(ArtifactoryServer.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
[JIRA] (JENKINS-40257) Artifactory plugin DSL generic uploader does not resolve credentialsId
Title: Message Title
Mark R updated an issue
Jenkins / JENKINS-40257
Artifactory plugin DSL generic uploader does not resolve credentialsId
Change By:
Mark R
I am unable to get the artifactory plugin to work with a credentials ID using generic builds in a Jenkinsfile . The credentials work when using the statically configured UI. The credentials work when hard coding them in using username/password. The credentials do not work when referencing them with credentialsId.The stacktrace references GenericUploadExecutor.java line 52. This calls CredentialsConfig getUsername / getPassword which has a comment that says "This should not be used in order to retrieve credentials in the configuration - Use provideUsername, providePassword instead". I do not see where the credentialsId is resolved. Perhaps https://www.jfrog.com/jira/browse/HAP-810 missed this file.https://github.com/jenkinsci/artifactory-plugin/blob/e30d3b54a2f685d12f0ae65750b16c9d0c59c62e/src/main/java/org/jfrog/hudson/pipeline/executors/GenericUploadExecutor.javaRelevant Plugins:- Pipeline 2.3- Credentials 2.1.4- Artifactory plugin 2.8.1DSL snippet:{code:java}// works with hard coded creds. Does not work with credentialsIddef server = Artifactory.newServer url: 'http://artifactoryinstance:8081/artifactory', credentialsId: '377a7f24-6ce8-4a3c-b363-373549650b1f'def publishSpec = """{ "files": [ { "pattern": "build/*.json", "target": "jenkins-build-local/${env.JOB_NAME}/${env.BUILD_NUMBER}/" } ]}""";print publishSpec;def buildInfo = Artifactory.newBuildInfo()server.upload(publishSpec, buildInfo)server.publishBuildInfo(buildInfo){code}The artifactory access log indicates that the jenkins plugin is attempting to use anonymous creds:{noformat}2016-12-06 09:52:32,979 [DENIED DEPLOY] repository:path/file.json for anonymous/ipaddr.{noformat}{noformat}Stacktrace:java.io.IOException: remote file operation failed: /var/appl/jenkins/workspace/job/branch at hudson.remoting.Channel@1002c189:jknapdvh1: java.io.IOException: Failed to deploy file: HTTP response code: 401. HTTP response message: Unauthorized at hudson.FilePath.act(FilePath.java:1014) at hudson.FilePath.act(FilePath.java:996) at org.jfrog.hudson.pipeline.executors.GenericUploadExecutor.execution(GenericUploadExecutor.java:52) at org.jfrog.hudson.pipeline.steps.UploadStep$Execution.run(UploadStep.java:65) at org.jfrog.hudson.pipeline.steps.UploadStep$Execution.run(UploadStep.java:46) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousStepExecution.start(AbstractSynchronousStepExecution.java:40) at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:180) at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:124) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:117) at org.jfrog.hudson.pipeline.types.ArtifactoryServer.upload(ArtifactoryServer.java:121) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at
[JIRA] (JENKINS-40257) Artifactory plugin DSL generic uploader does not resolve credentialsId
Title: Message Title Mark R created an issue Jenkins / JENKINS-40257 Artifactory plugin DSL generic uploader does not resolve credentialsId Issue Type: Bug Assignee: Eyal Ben Moshe Components: artifactory-plugin Created: 2016/Dec/06 3:59 PM Environment: Jenkins 2.7.1, Artifactory 2.7.0 Priority: Critical Reporter: Mark R I am unable to get the artifactory plugin to work with a credentials ID using generic builds. The credentials work when using the statically configured UI. The credentials work when hard coding them in using username/password. The credentials do not work when referencing them with credentialsId. The stacktrace references GenericUploadExecutor.java line 52. This calls CredentialsConfig getUsername / getPassword which has a comment that says "This should not be used in order to retrieve credentials in the configuration - Use provideUsername, providePassword instead". I do not see where the credentialsId is resolved. Perhaps https://www.jfrog.com/jira/browse/HAP-810 missed this file. https://github.com/jenkinsci/artifactory-plugin/blob/e30d3b54a2f685d12f0ae65750b16c9d0c59c62e/src/main/java/org/jfrog/hudson/pipeline/executors/GenericUploadExecutor.java Relevant Plugins: Pipeline 2.3 Credentials 2.1.4 Artifactory plugin 2.8.1 DSL snippet: // works with hard coded creds. Does not
[JIRA] (JENKINS-38211) JenkinsFiles cannot run on Linux agent of Windows master
Title: Message Title
Mark R commented on JENKINS-38211
Re: JenkinsFiles cannot run on Linux agent of Windows master
It comes from this: https://github.com/jenkinsci/durable-task-plugin/blob/master/src/main/java/org/jenkinsci/plugins/durabletask/BourneShellScript.java
String s = script;
final Jenkins jenkins = Jenkins.getInstance();
if (!s.startsWith("#!") && jenkins != null) {
String defaultShell = jenkins.getInjector().getInstance(Shell.DescriptorImpl.class).getShellOrDefault(ws.getChannel());
s = "#!"+defaultShell+" -xe\n" + s;
}
shf.write(s, "UTF-8");
shf.chmod(0755);
The default shell for the node must be 'sh'. It should be configurable somewhere... I'll ask our build guys if that can be done. For some reason it doesn't like '#!sh'. In the mean time I am able to get it to work by manually setting the shell:
sh '#!/usr/bin/sh -xe\n env'
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
[JIRA] (JENKINS-38211) JenkinsFiles cannot run on Linux agent of Windows master
Title: Message Title
Mark R edited a comment on JENKINS-38211
Re: JenkinsFiles cannot run on Linux agent of Windows master
A coworker was able to grab the temporary script being run on the Linux agent. The line endings are fine (LF-only): {noformat} [agent].../durable-3ca81cbf:$ od -cxv script.sh000 # ! s h - x e \n e n v 212368732d206578650a766e014 {noformat} But he still sees the same error: {noformat} [agent].../durable-3ca81cbf:$ ./script.shbash: ./script.sh: sh: bad interpreter: No such file or directory {noformat} It looks to be a malformed shebang. Modifying the shebang to be an absolute path allowed the script to run successfully. {noformat} [agent].../durable-3ca81cbf:$ od -cxv mod.sh000 # ! / b i n / s h - x e \n e n 2123622f6e69732f2068782d0a656e65020 v 0076021 {noformat} I'm now looking into if that is configurable.
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-38211) JenkinsFiles cannot run on Linux agent of Windows master
Title: Message Title Mark R commented on JENKINS-38211 Re: JenkinsFiles cannot run on Linux agent of Windows master A coworker was able to grab the temporary script being run on the Linux agent. The line endings are fine (LF-only): [agent].../durable-3ca81cbf: $ od -cxv script.sh 000 # ! s h - x e \n e n v 2123 6873 2d20 6578 650a 766e 014 But he still sees the same error: [agent].../durable-3ca81cbf: $ ./script.sh bash: ./script.sh: sh: bad interpreter: No such file or directory It looks to be a malformed shebang. Modifying the shebang to be an absolute path allowed the script to run successfully. [agent].../durable-3ca81cbf: $ od -cxv mod.sh 000 # ! / b i n / s h - x e \n e n 2123 622f 6e69 732f 2068 782d 0a65 6e65 020 v 0076 021 I'm now looking into if that is configurable. 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-38211) JenkinsFiles cannot run on Linux agent of Windows master
Title: Message Title Mark R commented on JENKINS-38211 Re: JenkinsFiles cannot run on Linux agent of Windows master Any progress on this? This is a showstopper for us as we are unable to run linux shell scripts. 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] [docker-build-publish-plugin] (JENKINS-29932) Docker build publish plugin throws error "Please login prior to push" after build the image
Title: Message Title Mark R commented on JENKINS-29932 Re: Docker build publish plugin throws error "Please login prior to push" after build the image I attached a debugger and managed to figure out my issue. My /home/jenkins/.dockercfg file had both a http and https url endpoint for my registry. The https endpoint had the correct password set. The http one did not. This may have something to do with me recently changing my password. To correct it I removed the stale http entry. 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-build-publish-plugin] (JENKINS-29932) Docker build publish plugin throws error "Please login prior to push" after build the image
Title: Message Title Mark R edited a comment on JENKINS-29932 Re: Docker build publish plugin throws error "Please login prior to push" after build the image I am having the same issue. I have the latest version of the plugin. 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-build-publish-plugin] (JENKINS-29932) Docker build publish plugin throws error "Please login prior to push" after build the image
Title: Message Title Mark R commented on JENKINS-29932 Re: Docker build publish plugin throws error "Please login prior to push" after build the image I am having the same issue. 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-build-publish-plugin] (JENKINS-33116) Not logging in on new slave agent in kubernetes.
Title: Message Title Mark R commented on JENKINS-33116 Re: Not logging in on new slave agent in kubernetes. I am also hitting this issue. 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-build-publish-plugin] (JENKINS-35000) Docker build on linux slave fails due to '\' backslash
Title: Message Title Mark R commented on JENKINS-35000 Re: Docker build on linux slave fails due to '\' backslash Pull request @ https://github.com/jenkinsci/docker-build-publish-plugin/pull/42 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-build-publish-plugin] (JENKINS-35000) Docker build on linux slave fails due to '\' backslash
Title: Message Title
Mark R edited a comment on JENKINS-35000
Re: Docker build on linux slave fails due to '\' backslash
Due Possibly due to this line (DockerBuilder.java):{code:java}FilePath context = defined(expandAll(getBuildContext())) ? new FilePath(new File(expandAll(getBuildContext(: build.getWorkspace();{code}Master is windows host so File is created with windows slash style.Could do something similar to what getWorkspace() does in AbstractBuilder by accessing the getBuiltOn() node if it is not null and creating a path from there.
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-build-publish-plugin] (JENKINS-35000) Docker build on linux slave fails due to '\' backslash
Title: Message Title Mark R commented on JENKINS-35000 Re: Docker build on linux slave fails due to '\' backslash Due to this line (DockerBuilder.java): FilePath context = defined(expandAll(getBuildContext())) ? new FilePath(new File(expandAll(getBuildContext( : build.getWorkspace(); Master is windows host so File is created with windows slash style. Could do something similar to what getWorkspace() does in AbstractBuilder by accessing the getBuiltOn() node if it is not null and creating a path from there. 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-build-publish-plugin] (JENKINS-35000) Docker build on linux slave fails due to '\' backslash
Title: Message Title
Mark R updated an issue
Jenkins / JENKINS-35000
Docker build on linux slave fails due to '\' backslash
Change By:
Mark R
The plugin is failing while running on a linux slave node. I have the "Build Context" set to "helloworld/build". It appears somewhere alone the line that is being translated into "helloworld\build" which is causing issues on the linux agent. See log below. Plugin version 1.2.2 (latest) Docker version 1.8.2-el7, build a01dc02/1.8.2Note that I have a node in a different environment running docker 1.9.1 and I don't encounter this issue.{noformat}docker build -t registry/repository/helloworld:v1.0.0 --no-cache=true --pull=true helloworld\buildunable to prepare context: unable to evaluate symlinks in context path: lstat /var/appl/jenkins/workspace/workspace/helloworld\build: no such file or directoryBuild step 'Docker Build and Publish' marked build as failure[BFA] Scanning build for known causes...{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-build-publish-plugin] (JENKINS-35000) Docker build on linux slave fails due to '\' backslash
Title: Message Title Mark R created an issue Jenkins / JENKINS-35000 Docker build on linux slave fails due to '\' backslash Issue Type: Bug Assignee: Carlos Sanchez Components: docker-build-publish-plugin Created: 2016/May/20 7:57 PM Priority: Major Reporter: Mark R The plugin is failing while running on a linux slave node. I have the "Build Context" set to "helloworld/build". It appears somewhere alone the line that is being translated into "helloworld\build" which is causing issues on the linux agent. See log below. Docker version 1.8.2-el7, build a01dc02/1.8.2 Note that I have a node in a different environment running docker 1.9.1 and I don't encounter this issue. docker build -t registry/repository/helloworld:v1.0.0 --no-cache=true --pull=true helloworld\build unable to prepare context: unable to evaluate symlinks in context path: lstat /var/appl/jenkins/workspace/workspace/helloworld\build: no such file or directory Build step 'Docker Build and Publish' marked build as failure [BFA] Scanning build for known causes...
[JIRA] [docker-build-step-plugin] (JENKINS-24071) Docker build step tries to build on master and not slave
Title: Message Title Mark R commented on JENKINS-24071 Re: Docker build step tries to build on master and not slave Why is this not fixed? This plugin is useless to us if it can't build docker images on remote machines. 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-build-step-plugin] (JENKINS-24071) Docker build step tries to build on master and not slave
Title: Message Title Mark R edited a comment on JENKINS-24071 Re: Docker build step tries to build on master and not slave Why is this not This really needs to get fixed ? . This plugin is useless of no use to us if it can't build docker images on remote machines. 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] [gradle-plugin] (JENKINS-32130) Gradle Wrapper not working when gradlew wrapper is in a subfolder
Title: Message Title
Mark R updated an issue
Jenkins / JENKINS-32130
Gradle Wrapper not working when gradlew wrapper is in a subfolder
Change By:
Mark R
If the gradlew script is neither in the same folder as the build script specified by the jenkins gradle plugin nor the root workspace directory it will not be picked up. This is a problem for users of RTC SCM since it may create an additional directory based on the component name.Example: {noformat} .jazzignore/mycomponentmycomponent|__gradle|__wrapper|__my-project|__build.gradle|__another-folder|__gradlew.bat {noformat} Looking at the code on github it only tries to find gradlew.bat in the root workspace directory and the same directory as build.gradle (when specified in the options).Note that in this directory layout the my-project is not part of a multi-project build but does not live in the component directory.
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] [gradle-plugin] (JENKINS-32130) Gradle Wrapper not working when gradlew wrapper is in a subfolder
Title: Message Title Mark R updated an issue Jenkins / JENKINS-32130 Gradle Wrapper not working when gradlew wrapper is in a subfolder Change By: Mark R If the gradlew script is neither in the same folder as the build script specified by the jenkins gradle plugin nor the root workspace directory it will not be picked up. This is a problem for users of RTC SCM since it may create an additional directory based on the component name.Example: .jazzignore/mycomponentmycomponent|__gradle|__wrapper|__my-project|__build.gradle|__another-folder|__gradlew.batLooking at the code on github it only tries to find gradlew.bat in the root workspace directory and the same directory as build.gradle (when specified in the options).Note that in this directory layout the my-project is not part of a multi-project build but does not live in the component directory. 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] [gradle-plugin] (JENKINS-32130) Gradle Wrapper not working when gradlew wrapper is in a subfolder
Title: Message Title Mark R updated an issue Jenkins / JENKINS-32130 Gradle Wrapper not working when gradlew wrapper is in a subfolder Change By: Mark R Summary: Gradle Wrapper not working when gradlew wrapper is in a sub folder subfolder 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] [gradle-plugin] (JENKINS-32130) Gradle Wrapper not working when wrapper is in a sub folder
Title: Message Title Mark R created an issue Jenkins / JENKINS-32130 Gradle Wrapper not working when wrapper is in a sub folder Issue Type: Bug Assignee: Gregory Boissinot Components: gradle-plugin Created: 17/Dec/15 4:45 PM Priority: Major Reporter: Mark R If the gradlew script is neither in the same folder as the build script specified by the jenkins gradle plugin nor the root workspace directory it will not be picked up. This is a problem for users of RTC SCM since it may create an additional directory based on the component name. Example: .jazzignore/mycomponent mycomponent __gradle __wrapper __my-project
[JIRA] [gradle-plugin] (JENKINS-32130) Gradle Wrapper not working when gradlew wrapper is in a subfolder
Title: Message Title
Mark R edited a comment on JENKINS-32130
Re: Gradle Wrapper not working when gradlew wrapper is in a subfolder
After further investigation I have found a way to do what I want with the current gradle plugin. It wasn't clear to me that "Root Build script" property is supposed to be a directory and corresponds to the "Root Build Script Dir" checkbox.Configuration:Use Gradle WrapperCheck "From Root Build Script Dir"Root Build script: ${workspace}/mycomponentBuild File: my-project/build.gradle
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] [gradle-plugin] (JENKINS-32130) Gradle Wrapper not working when gradlew wrapper is in a subfolder
Title: Message Title Mark R resolved as Fixed Found a way to configure the plugin to do what I need. Jenkins / JENKINS-32130 Gradle Wrapper not working when gradlew wrapper is in a subfolder Change By: Mark R Status: Open Resolved Resolution: Fixed 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] [gradle-plugin] (JENKINS-32130) Gradle Wrapper not working when gradlew wrapper is in a subfolder
Title: Message Title
Mark R commented on JENKINS-32130
Re: Gradle Wrapper not working when gradlew wrapper is in a subfolder
After further investigation I have found a way to do what I want with the current gradle plugin. I wasn't clear that "Root Build script" property is supposed to be a directory and corresponds to the "Root Build Script Dir" checkbox.
Configuration: Use Gradle Wrapper Check "From Root Build Script Dir" Root Build script: $ {workspace}
/mycomponent Build File: my-project/build.gradle
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] [gradle-plugin] (JENKINS-32130) Gradle Wrapper not working when gradlew wrapper is in a subfolder
Title: Message Title
Mark R edited a comment on JENKINS-32130
Re: Gradle Wrapper not working when gradlew wrapper is in a subfolder
After further investigation I have found a way to do what I want with the current gradle plugin. It wasn't clear to me that the "Root Build script" property is supposed to be a directory and corresponds to the "Root Build Script Dir" checkbox.Configuration: {noformat} Use Gradle WrapperCheck "From Root Build Script Dir"Root Build script: $ {workspace} /mycomponentBuild File: my-project/build.gradle {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] [gradle-plugin] (JENKINS-32130) Gradle Wrapper not working when gradlew wrapper is in a subfolder
Title: Message Title
Mark R updated an issue
Jenkins / JENKINS-32130
Gradle Wrapper not working when gradlew wrapper is in a subfolder
Change By:
Mark R
If the gradlew script is neither in the same folder as the build script specified by the jenkins gradle plugin nor the root workspace directory it will not be picked up. This is a problem for users of RTC SCM since it may create an additional directory based on the component name.Example:{noformat}. jazzignore jazz5 /mycomponentmycomponent|__gradle|__wrapper|__my-project|__build.gradle|__another-folder|__gradlew.bat{noformat}Looking at the code on github it only tries to find gradlew.bat in the root workspace directory and the same directory as build.gradle (when specified in the options).Note that in this directory layout the my-project is not part of a multi-project build but does not live in the component directory.
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] [gradle-plugin] (JENKINS-32130) Gradle Wrapper not working when gradlew wrapper is in a subfolder
Title: Message Title
Mark R edited a comment on JENKINS-32130
Re: Gradle Wrapper not working when gradlew wrapper is in a subfolder
Found After further investigation I have found a way to configure the plugin to do what I need want with the current gradle plugin . It wasn't clear to me that the "Root Build script" property is supposed to be a directory and corresponds to the "Root Build Script Dir" checkbox.Configuration:Use Gradle WrapperCheck "From Root Build Script Dir"Root Build script: ${workspace}/mycomponentBuild File: my-project/build.gradle
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] [gradle-plugin] (JENKINS-32130) Gradle Wrapper not working when gradlew wrapper is in a subfolder
Title: Message Title
Mark R updated an issue
Jenkins / JENKINS-32130
Gradle Wrapper not working when gradlew wrapper is in a subfolder
Change By:
Mark R
Comment:
After further investigation I have found a way to do what I want with the current gradle plugin. It wasn't clear to me that the "Root Build script" property is supposed to be a directory and corresponds to the "Root Build Script Dir" checkbox.Configuration:Use Gradle WrapperCheck "From Root Build Script Dir"Root Build script: ${workspace}/mycomponentBuild File: my-project/build.gradle
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] [gradle-plugin] (JENKINS-32130) Gradle Wrapper not working when gradlew wrapper is in a subfolder
Title: Message Title
Mark R edited a comment on JENKINS-32130
Re: Gradle Wrapper not working when gradlew wrapper is in a subfolder
After further investigation I have found a way to do what I want with the current gradle plugin. It wasn't clear to me that the "Root Build script" property is supposed to be a directory and corresponds to the "Root Build Script Dir" checkbox.Configuration:Use Gradle WrapperCheck "From Root Build Script Dir"Root Build script: ${workspace}/mycomponentBuild File: my-project/build.gradle
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] [gradle-plugin] (JENKINS-32130) Gradle Wrapper not working when gradlew wrapper is in a subfolder
Title: Message Title
Mark R edited a comment on JENKINS-32130
Re: Gradle Wrapper not working when gradlew wrapper is in a subfolder
After further investigation I have found a way to do what I want with the current gradle plugin. I It wasn't clear that "Root Build script" property is supposed to be a directory and corresponds to the "Root Build Script Dir" checkbox.Configuration:Use Gradle WrapperCheck "From Root Build Script Dir"Root Build script: ${workspace}/mycomponentBuild File: my-project/build.gradle
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] [jacoco-plugin] (JENKINS-25616) Support for coverage.xml generated by Android tools
Mark R commented on JENKINS-25616 Support for coverage.xml generated by Android tools There still is a related issue of having to statically configure the includes/excludes in the plugin configuration. This does not allow for dynamically determining which files to include/exclude. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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.
