[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title Matthew Smeeth commented on JENKINS-60213 Re: P4CLIENT environment variable non-reentrant There seems to be underlying issues with the executor number in Jenkins core. JENKINS-48882, JENKINS-24679, JENKINS-7357, JENKINS-4756. Our testing confirms that we calculate the correct executor number for the client, however the environment variable EXECUTOR_NUMBER set by Jenkins (hudson.model.Computer) seems always be incorrect with concurrent execution. Closing this issue as we have resolved the client name part of the issue. Please raise this against Jenkins core if you require the EXECUTOR_NUMBER to be fixed. 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.203186.1574180065000.5153.1583924580421%40Atlassian.JIRA.
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title Matthew Smeeth closed an issue as Fixed Jenkins / JENKINS-60213 P4CLIENT environment variable non-reentrant Change By: Matthew Smeeth Status: Open Closed Resolution: Fixed 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.203186.1574180065000.5155.1583924580458%40Atlassian.JIRA.
[JIRA] (JENKINS-61156) Regression: P4 Plugin 1.10.10 trigger doesn't run jobs
Title: Message Title Matthew Smeeth commented on JENKINS-61156 Re: Regression: P4 Plugin 1.10.10 trigger doesn't run jobs Hi William Brode, I'm a bit surprised that it would work without build access, however given that anonymous user has read access on your system, It's possible that's all that's needed to avoid this issue. However once you upgrade to 1.10.11 I think you'll almost certainly hit this issue due to extra security measures we've implemented. For now unfortunately I'm going to revert the changes, with a plan to look into implementing this another way in the future. FYI Adam Butler 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.204686.158215634.4195.1583859360264%40Atlassian.JIRA.
[JIRA] (JENKINS-61156) Regression: P4 Plugin 1.10.10 trigger doesn't run jobs
Title: Message Title Matthew Smeeth edited a comment on JENKINS-61156 Re: Regression: P4 Plugin 1.10.10 trigger doesn't run jobs Hi [~wbrode], what access does can you confirm whether anonymous users have build and read permissions set in on your Jenkins server ?The reason I ask is because I've observed that if you allow anonymous users read and build access(or anything higher) on your Jenkins server, the perforce triggers will still work as expected. Whereas if Jenkins is set up to only allow authenticated users read and build access(or higher), that's when I'm see the issue. 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.204686.158215634.697.1582804200259%40Atlassian.JIRA.
[JIRA] (JENKINS-61156) Regression: P4 Plugin 1.10.10 trigger doesn't run jobs
Title: Message Title Matthew Smeeth commented on JENKINS-61156 Re: Regression: P4 Plugin 1.10.10 trigger doesn't run jobs Hi William Brode, what access does anonymous users have set in Jenkins? The reason I ask is because I've observed that if you allow anonymous users read and build access(or anything higher) on your Jenkins server, the perforce triggers will still work as expected. Whereas if Jenkins is set up to only allow authenticated users read and build access(or higher), that's when I'm see the issue. 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.204686.158215634.691.1582804080200%40Atlassian.JIRA.
[JIRA] (JENKINS-61156) Regression: P4 Plugin 1.10.10 trigger doesn't run jobs
Title: Message Title Matthew Smeeth commented on JENKINS-61156 Re: Regression: P4 Plugin 1.10.10 trigger doesn't run jobs I have just checked this. In P4Hook we use an anonymous thread to run the job. If we call getAllItems(to find the list of Jobs) inside the thread it seems to ignore your credentials and return no jobs. We may need to back out https://github.com/jenkinsci/p4-plugin/pull/116/files to fix this. Adam Butler, are there alternatives for this fix? Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204686.158215634.7250.1582732200420%40Atlassian.JIRA.
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title
Matthew Smeeth edited a comment on JENKINS-60213
Re: P4CLIENT environment variable non-reentrant
Hi, I've written an automated test to reproduce this issue, Looking into it further, it looks to me like the P4_CLIENT variable is actually correct, and it's actually the EXECUTOR NUMBER that is wrong in your script. I can demonstrate this by putting an extra bit of debugging into the p4 plugin when running jobs. I have modified my build so that it outputs the executor number as the job is executing and this is what I get: {code:java}Obtained concurrentBuildsTest/jenkinsfile from p4-brunoCred-//depot/... //jenkins-${NODE_NAME}${JOB_NAME}${EXECUTOR_NUMBER}/...Running in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeRunning on Jenkins in /var/jenkins_home/workspace/concurrentBuildsTestProject[Pipeline] {[Pipeline] stage[Pipeline] { (testStage)[Pipeline] script[Pipeline] {[Pipeline] dirRunning in /var/jenkins_home/workspace/concurrentBuildsTestProject/test[Pipeline] {[Pipeline] checkoutExecutor no at runtime:0 Extra debugging I've added to the p4 plugin .. .. .. + concurrentBuildsTest/script.sh = WORKSPACE: /var/jenkins_home/workspace/concurrentBuildsTestProject < CORRECT P4_CLIENT: jenkins-master-concurrentBuildsTestProject-0 CORRECT EXECUTOR NUMBER: 1 < Wrong executor number = ERROR - Bad Workspace ERROR - Bad P4 Client .. ..Finished: FAILURE{code} I have run this several times and every time the job fails, the result is the same, the workspace and client are correct, and the executor number outputted by the script is incorrect.I'm theorising that this is because when builds are running concurrently, in between the sync and the running of the script, the executor number gets overridden by the other jobs, hence it ends up incorrect when the script runs. Therefore I don't think the script we're using is suitable for testing this issue. It's worth noting I am using the latest changes which contains [https://github.com/jenkinsci/p4-plugin/pull/113]. Which fixes an issue very similar to this, where the workspace was being set wrong. I believe this was why you were getting a different p4 client and workspace. [~jbateman], when available please can you retest your original scenario using a build with [https://github.com/jenkinsci/p4-plugin/pull/113] in. As I suspect this may fix your issue.
Add Comment
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title
Matthew Smeeth edited a comment on JENKINS-60213
Re: P4CLIENT environment variable non-reentrant
Hi, I've written an automated test to reproduce this issue, Looking into it further, it looks to me like the P4_CLIENT variable is actually correct, and it's actually the EXECUTOR NUMBER that is wrong in your script. I can demonstrate this by putting an extra bit of debugging into the p4 plugin when running jobs. I have modified my build so that it outputs the executor number as the job is executing and this is what I get: {code:java}Obtained concurrentBuildsTest/jenkinsfile from p4-brunoCred-//depot/... //jenkins-${NODE_NAME}${JOB_NAME}${EXECUTOR_NUMBER}/... Running in Durability level: MAX_SURVIVABILITY [Pipeline] Start of Pipeline [Pipeline] nodeRunning nodeRunning on Jenkins in /var/jenkins_home/workspace/concurrentBuildsTestProject [Pipeline] { [Pipeline] stage [Pipeline] { (testStage) [Pipeline] script [Pipeline] { [Pipeline] dirRunning dirRunning in /var/jenkins_home/workspace/concurrentBuildsTestProject/test [Pipeline] { [Pipeline] checkoutExecutor checkoutExecutor no at runtime:0 Extra debugging I've added to the p4 plugin .. .. .. + concurrentBuildsTest/script.sh = WORKSPACE: /var/jenkins_home/workspace/concurrentBuildsTestProject < CORRECT P4_CLIENT: jenkins-master-concurrentBuildsTestProject-0 CORRECT EXECUTOR NUMBER: 1 < Wrong executor number =ERROR - Bad Workspace ERROR - Bad P4 Client .. ..Finished: FAILURE{code} I have run this several times and every time the job fails, the result is the same, the workspace and client are correct, and the executor number outputted by the script is incorrect.I'm theorising that this is because when builds are running concurrently, in between the sync and the running of the script, the executor number gets overridden by the other jobs, hence it ends up incorrect when the script runs. Therefore I don't think the script we're using is suitable for testing this issue. It's worth noting I am using the latest changes which contains [https://github.com/jenkinsci/p4-plugin/pull/113]. Which fixes an issue very similar to this, where the workspace was being set wrong. I believe this was why you were getting a different p4 client and workspace. [~jbateman], when available please can you retest your original scenario using a build with [https://github.com/jenkinsci/p4-plugin/pull/113] in. As I suspect this may fix your issue.
Add Comment
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title
Matthew Smeeth edited a comment on JENKINS-60213
Re: P4CLIENT environment variable non-reentrant
Hi, I've written an automated test to reproduce this issue, Looking into it further, it looks to me like the P4_CLIENT variable is actually correct, and it's actually the EXECUTOR NUMBER that is wrong in your script. I can demonstrate this by putting an extra bit of debugging into the p4 plugin when running jobs. I have modified my build so that it outputs the executor number as the job is executing and this is what I get: {code:java}Obtained concurrentBuildsTest/jenkinsfile from p4-brunoCred-//depot/... //jenkins-${NODE_NAME}${JOB_NAME}${EXECUTOR_NUMBER}/...Running in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeRunning on Jenkins in /var/jenkins_home/workspace/concurrentBuildsTestProject[Pipeline] {[Pipeline] stage[Pipeline] { (testStage)[Pipeline] script[Pipeline] {[Pipeline] dirRunning in /var/jenkins_home/workspace/concurrentBuildsTestProject/test[Pipeline] {[Pipeline] checkoutExecutor no at runtime:0 Extra debugging I've added to the p4 plugin .. .. .. + concurrentBuildsTest/script.sh = WORKSPACE: /var/jenkins_home/workspace/concurrentBuildsTestProject < CORRECT P4_CLIENT: jenkins-master-concurrentBuildsTestProject-0 CORRECT EXECUTOR NUMBER: 1 < Wrong executor number =ERROR - Bad WorkspaceERROR - Bad P4 Client .. ..Finished: FAILURE{code} I have run this several times and every time the job fails, the result is the same, the workspace and client are correct, and the executor number outputted by the script is incorrect.I'm theorising that this is because when builds are running concurrently, in between the sync and the running of the script, the executor number gets overridden by the other jobs, hence it ends up incorrect when the script runs. Therefore I don't think the script we're using is suitable for testing this issue. It's worth noting I am using the latest changes which contains [https://github.com/jenkinsci/p4-plugin/pull/113]. Which fixes an issue very similar to this, where the workspace was being set wrong. I believe this was why you were getting a different p4 client and workspace. [~jbateman], when available please can you retest your original scenario using a build with [https://github.com/jenkinsci/p4-plugin/pull/113] in. As I suspect this may fix your issue.
Add Comment
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title
Matthew Smeeth edited a comment on JENKINS-60213
Re: P4CLIENT environment variable non-reentrant
Hi, I've written an automated test to reproduce this issue, and looking Looking into it further . It , it looks to me like the P4_CLIENT variable is actually correct, and it's actually the EXECUTOR NUMBER that is wrong in your script. I can demonstrate this by putting an extra bit of debugging into the p4 plugin when running jobs. I have modified my build so that it outputs the executor number as the job is executing and this is what I get: Obtained concurrentBuildsTest/jenkinsfile from p4-brunoCred-//depot/... //jenkins-${NODE_NAME}-${JOB_NAME}-${EXECUTOR_NUMBER}/...Running in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeRunning on [Jenkins|http://localhost:5003/computer/(master)/] in /var/jenkins_home/workspace/concurrentBuildsTestProject[Pipeline] {[Pipeline] stage[Pipeline] { (testStage)[Pipeline] script[Pipeline] {[Pipeline] dirRunning in /var/jenkins_home/workspace/concurrentBuildsTestProject/test[Pipeline] {[Pipeline] checkoutExecutor no at runtime:0 Extra debugging I've added to the p4 plugin..+ concurrentBuildsTest/script.sh= WORKSPACE: /var/jenkins_home/workspace/concurrentBuildsTestProject < CORRECTP4_CLIENT: jenkins-master-concurrentBuildsTestProject-0 CORRECTEXECUTOR NUMBER: 1 < Wrong executor number= * ** * ** ERROR - Bad Workspace*** ERROR - Bad P4 ClientFinished: FAILURE I have run this several times and every time the job fails, the result is the same, the workspace and client are correct, and the executor number outputted by the script is incorrect.I'm theorising that this is because when builds are running concurrently, in between the sync and the running of the script, the executor number gets overridden by the other jobs, hence it ends up incorrect when the script runs. Therefore I don't think the script we're using is suitable for testing this issue. It's worth noting I am using the latest changes which contains [https://github.com/jenkinsci/p4-plugin/pull/113]. Which fixes an issue very similar to this, where the workspace was being set wrong. I believe this was why you were getting a different p4 client and workspace. [~jbateman], when available please can you retest your original scenario using a build with [https://github.com/jenkinsci/p4-plugin/pull/113] in. As I suspect this may fix your issue.
Add Comment
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title
Matthew Smeeth edited a comment on JENKINS-60213
Re: P4CLIENT environment variable non-reentrant
Hi, I've written an automated test to reproduce this issue, Looking into it further, it looks to me like the P4_CLIENT variable is actually correct, and it's actually the EXECUTOR NUMBER that is wrong in your script. I can demonstrate this by putting an extra bit of debugging into the p4 plugin when running jobs. I have modified my build so that it outputs the executor number as the job is executing and this is what I get: {code:java} Obtained concurrentBuildsTest/jenkinsfile from p4-brunoCred-//depot/... //jenkins-${NODE_NAME} - ${JOB_NAME} - ${EXECUTOR_NUMBER}/... Running in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeRunning on [ Jenkins |http://localhost:5003/computer/(master)/] in /var/jenkins_home/workspace/concurrentBuildsTestProject[Pipeline] {[Pipeline] stage[Pipeline] { (testStage)[Pipeline] script[Pipeline] {[Pipeline] dirRunning in /var/jenkins_home/workspace/concurrentBuildsTestProject/test[Pipeline] {[Pipeline] checkoutExecutor no at runtime:0 Extra debugging I've added to the p4 plugin .. .. .. + concurrentBuildsTest/script.sh = WORKSPACE: /var/jenkins_home/workspace/concurrentBuildsTestProject < CORRECT P4_CLIENT: jenkins-master-concurrentBuildsTestProject-0 CORRECT EXECUTOR NUMBER: 1 < Wrong executor number = * ** *** ERROR - Bad Workspace *** ERROR - Bad P4 Client .. .. Finished: FAILURE {code} I have run this several times and every time the job fails, the result is the same, the workspace and client are correct, and the executor number outputted by the script is incorrect.I'm theorising that this is because when builds are running concurrently, in between the sync and the running of the script, the executor number gets overridden by the other jobs, hence it ends up incorrect when the script runs. Therefore I don't think the script we're using is suitable for testing this issue. It's worth noting I am using the latest changes which contains [https://github.com/jenkinsci/p4-plugin/pull/113]. Which fixes an issue very similar to this, where the workspace was being set wrong. I believe this was why you were getting a different p4 client and workspace. [~jbateman], when available please can you retest your original scenario using a build with [https://github.com/jenkinsci/p4-plugin/pull/113] in. As I suspect this may fix your issue.
Add Comment
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title
Matthew Smeeth commented on JENKINS-60213
Re: P4CLIENT environment variable non-reentrant
Hi, I've written an automated test to reproduce this issue, and looking into it further. It looks to me like the P4_CLIENT variable is actually correct, and it's actually the EXECUTOR NUMBER that is wrong in your script. I can demonstrate this by putting an extra bit of debugging into the p4 plugin when running jobs. I have modified my build so that it outputs the executor number as the job is executing and this is what I get: Obtained concurrentBuildsTest/jenkinsfile from p4-brunoCred-//depot/... //jenkins-${NODE_NAME}${JOB_NAME}${EXECUTOR_NUMBER}/... Running in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeRunning on Jenkins in /var/jenkins_home/workspace/concurrentBuildsTestProject[Pipeline] {[Pipeline] stage[Pipeline] { (testStage)[Pipeline] script[Pipeline] {[Pipeline] dirRunning in /var/jenkins_home/workspace/concurrentBuildsTestProject/test[Pipeline] {[Pipeline] checkoutExecutor no at runtime:0 Extra debugging I've added to the p4 plugin .. .. .. + concurrentBuildsTest/script.sh = WORKSPACE: /var/jenkins_home/workspace/concurrentBuildsTestProject < CORRECT P4_CLIENT: jenkins-master-concurrentBuildsTestProject-0 CORRECT EXECUTOR NUMBER: 1 < Wrong executor number =
ERROR - Bad Workspace
ERROR - Bad P4 Client .. ..
Finished: FAILURE I have run this several times and every time the job fails, the result is the same, the workspace and client are correct, and the executor number outputted by the script is incorrect. I'm theorising that this is because when builds are running concurrently, in between the sync and the running of the script, the executor number gets overridden by the other jobs, hence it ends up incorrect when the script runs. Therefore I don't think the script we're using is suitable for testing this issue. It's worth noting I am using the latest changes which contains https://github.com/jenkinsci/p4-plugin/pull/113. Which fixes an issue very similar to this, where the workspace was being set wrong. I believe this was why you were getting a different p4 client and workspace. James Bateman, when available please can you retest your original scenario using a build with https://github.com/jenkinsci/p4-plugin/pull/113 in. As I suspect this may fix your issue.
[JIRA] (JENKINS-59484) EXECUTOR_NUMBER is always expanded to '0' in workspace name when checking out with Perforce to a subdirectory
Title: Message Title Matthew Smeeth closed an issue as Fixed Fixed in https://github.com/jenkinsci/p4-plugin/pull/113 Jenkins / JENKINS-59484 EXECUTOR_NUMBER is always expanded to '0' in workspace name when checking out with Perforce to a subdirectory Change By: Matthew Smeeth Status: In Progress Closed Resolution: Fixed Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to
[JIRA] (JENKINS-60213) P4CLIENT environment variable non-reentrant
Title: Message Title Matthew Smeeth assigned an issue to Matthew Smeeth Jenkins / JENKINS-60213 P4CLIENT environment variable non-reentrant Change By: Matthew Smeeth Assignee: Matthew Smeeth Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203186.1574180065000.13673.1576755540136%40Atlassian.JIRA.
[JIRA] (JENKINS-59484) EXECUTOR_NUMBER is always expanded to '0' in workspace name when checking out with Perforce to a subdirectory
Title: Message Title Matthew Smeeth assigned an issue to Matthew Smeeth Jenkins / JENKINS-59484 EXECUTOR_NUMBER is always expanded to '0' in workspace name when checking out with Perforce to a subdirectory Change By: Matthew Smeeth Assignee: Matthew Smeeth Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202099.1569244102000.10614.1576600920290%40Atlassian.JIRA.
[JIRA] (JENKINS-59484) EXECUTOR_NUMBER is always expanded to '0' in workspace name when checking out with Perforce to a subdirectory
Title: Message Title Matthew Smeeth started work on JENKINS-59484 Change By: Matthew Smeeth Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202099.1569244102000.10610.1576600860466%40Atlassian.JIRA.
[JIRA] (JENKINS-60321) Multibranch pipeline with default Jenkinsfile fails when scanning p4 streams
Title: Message Title Matthew Smeeth resolved as Fixed Fixed, it should now use the default Jenkinsfile when using the Multibranch with defaults plugin. Jenkins / JENKINS-60321 Multibranch pipeline with default Jenkinsfile fails when scanning p4 streams Change By: Matthew Smeeth Status: In Progress Resolved Resolution: Fixed Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to
[JIRA] (JENKINS-60321) Multibranch pipeline with default Jenkinsfile fails when scanning p4 streams
Title: Message Title Matthew Smeeth updated an issue Jenkins / JENKINS-60321 Multibranch pipeline with default Jenkinsfile fails when scanning p4 streams Change By: Matthew Smeeth Labels: P4_A P4_VERIFY Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203319.157495971.5612.1576076341601%40Atlassian.JIRA.
[JIRA] (JENKINS-60321) Multibranch pipeline with default Jenkinsfile fails when scanning p4 streams
Title: Message Title Matthew Smeeth started work on JENKINS-60321 Change By: Matthew Smeeth Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203319.157495971.5614.1576076342022%40Atlassian.JIRA.
[JIRA] (JENKINS-60321) Multibranch pipeline with default Jenkinsfile fails when scanning p4 streams
Title: Message Title Matthew Smeeth assigned an issue to Matthew Smeeth Jenkins / JENKINS-60321 Multibranch pipeline with default Jenkinsfile fails when scanning p4 streams Change By: Matthew Smeeth Assignee: Matthew Smeeth Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203319.157495971.5603.1576076161971%40Atlassian.JIRA.
[JIRA] (JENKINS-60142) ConnectionHelper.java constructors call connectionRetry()
Title: Message Title Matthew Smeeth closed an issue as Won't Fix Not fixing due to being able to prevent login -s being called by enabling the "hide tickets" option. Jenkins / JENKINS-60142 ConnectionHelper.java constructors call connectionRetry() Change By: Matthew Smeeth Status: Open Closed Resolution: Won't Fix Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to
[JIRA] (JENKINS-60142) ConnectionHelper.java constructors call connectionRetry()
Title: Message Title Matthew Smeeth edited a comment on JENKINS-60142 Re: ConnectionHelper.java constructors call connectionRetry() Hi [~jbateman],"getEnvironment" fetches various Perforce variables including p4ticket, unfortunately some of our customers require a Perforce ticket to be added to the environment for their scripts. However if If you set the "Hide TICKET" option in the "Perforce: Secure P4_TICKET" section on the Jenkins configuration page, this will prevent Jenkins from getting a ticket when you call the "getEnvironment" function. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203003.1573562093000.3545.1575976982184%40Atlassian.JIRA.
[JIRA] (JENKINS-60142) ConnectionHelper.java constructors call connectionRetry()
Title: Message Title Matthew Smeeth commented on JENKINS-60142 Re: ConnectionHelper.java constructors call connectionRetry() Hi James Bateman, "getEnvironment" fetches various Perforce variables including p4ticket, unfortunately some of our customers require a Perforce ticket to be added to the environment for their scripts. However if you set the "Hide TICKET" option in the "Perforce: Secure P4_TICKET" section on the Jenkins configuration page, this will prevent Jenkins from getting a ticket when you call the "getEnvironment" function. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203003.1573562093000.3543.1575976982014%40Atlassian.JIRA.
[JIRA] (JENKINS-50975) Concurrent Groovy Shared Library syncs on different jobs use same workspace root
Title: Message Title Matthew Smeeth commented on JENKINS-50975 Re: Concurrent Groovy Shared Library syncs on different jobs use same workspace root Hi Jay, I'm currently trying to reproduce your issue, so far I have been unable to. If possible could you share your library file? Thanks, Matthew Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.190124.1524607256000.2859.1565800380308%40Atlassian.JIRA.
[JIRA] (JENKINS-57945) p4 sync corrupts symlinks
Title: Message Title Matthew Smeeth commented on JENKINS-57945 Re: p4 sync corrupts symlinks Hi Michael, Do you possibly have text files nested within your symlinks? for example: //depot/path/symlink#1 (symlink) //depot/path/symlink/textfile#1 (text) Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199921.1560203497000.25926.1560344100181%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-52590) p4-plugin sets client root to null
Title: Message Title Matthew Smeeth updated JENKINS-52590 Jenkins / JENKINS-52590 p4-plugin sets client root to null Change By: Matthew Smeeth Status: Resolved Fixed but Unreleased Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55107) Modifying a global library stored in Perforce when replaying a job fails due file not being writable
Title: Message Title Matthew Smeeth updated an issue Jenkins / JENKINS-55107 Modifying a global library stored in Perforce when replaying a job fails due file not being writable Change By: Matthew Smeeth Modifying a global library stored in Perforce when replaying a job fails due file not being writable. Looks like when you replay a job in Jenkins and make a change to the library file, Jenkins then attempts to write to the file. Due to the file not being open for edit when Jenkins attempts to write to the file this subsequently fails. [ https://github.com/jenkinsci/p4-plugin/pull/85 ] Reproduction steps: * create a folder * add a library within the folder * create a pipeline job(inline script or jenkinsfile) within the folder * build the job at least once * select the replay option for one of your finished jobs * on the "replay job" screen modify the library file before you replay * replay the job by selecting the "run" button 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-55107) Modifying a global library stored in Perforce when replaying a job fails due file not being writable
Title: Message Title Matthew Smeeth created an issue Jenkins / JENKINS-55107 Modifying a global library stored in Perforce when replaying a job fails due file not being writable Issue Type: Bug Assignee: Unassigned Components: p4-plugin Created: 2018-12-10 16:07 Priority: Major Reporter: Matthew Smeeth Modifying a global library stored in Perforce when replaying a job fails due file not being writable. Looks like when you replay a job in Jenkins and make a change to the library file, Jenkins then attempts to write to the file. Due to the file not being open for edit when Jenkins attempts to write to the file this subsequently fails. https://github.com/jenkinsci/p4-plugin/pull/85 Add Comment
[JIRA] (JENKINS-39107) expose "Stream Codeline" as an environment variable
Title: Message Title Matthew Smeeth updated an issue Jenkins / JENKINS-39107 expose "Stream Codeline" as an environment variable Change By: Matthew Smeeth Labels: P4_VERIFY P4_A 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.
