[JIRA] (JENKINS-50975) Concurrent Groovy Shared Library syncs on different jobs use same workspace root
Title: Message Title Jay Spang commented on JENKINS-50975 Re: Concurrent Groovy Shared Library syncs on different jobs use same workspace root Hey Matthew Smeeth, I was wondering if you had any luck repro'ing the error? The key is to use "dynamically loaded" libraries (where you specify the `retriever` property). You also have to hit "Build Now" very rapidly to get it to repro. I hypothesize that p4groovy isn't changing the workspace root when it decides to append "_2" to the folder name. Since it works properly when specifying global libraries (that were previously loaded into the Jenkins global config), maybe it uses a slightly different code path. 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.5547.1566234180522%40Atlassian.JIRA.
[JIRA] (JENKINS-50975) Concurrent Groovy Shared Library syncs on different jobs use same workspace root
Title: Message Title Jay Spang commented on JENKINS-50975 Re: Concurrent Groovy Shared Library syncs on different jobs use same workspace root To be extra clear, it only repros for me with dynamically loaded libraries. If you import your library with... library 'static-global-library@now' it doesn't happen. But if you load your library with... library(identifier: 'dynamically-loaded-library@now', retriever: legacySCM( // ... ) )` it happens. Just click "Build Now" as rapidly as you you can 4-5 times. I can still send you a library if you'd like, but the failure happens before it even loads, so its contents don't matter. 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.2963.1565807100661%40Atlassian.JIRA.
[JIRA] (JENKINS-50975) Concurrent Groovy Shared Library syncs on different jobs use same workspace root
Title: Message Title
Jay Spang edited a comment on JENKINS-50975
Re: Concurrent Groovy Shared Library syncs on different jobs use same workspace root
To be extra clear, it only repros for me with _dynamically_ loaded libraries.If you import your library with... {code}library 'static-global-library@now'{code} it doesn't happen. But if you load your library with... {code}library(identifier: 'dynamically-loaded-library@now', retriever: legacySCM( // ... ) ) ` {code} it happens. Just click "Build Now" as rapidly as you you can 4-5 times.I can still send you a library if you'd like, but the failure happens before it even loads, so its contents don't matter.
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.2971.1565807100811%40Atlassian.JIRA.
[JIRA] (JENKINS-50975) Concurrent Groovy Shared Library syncs on different jobs use same workspace root
Title: Message Title
Jay Spang edited a comment on JENKINS-50975
Re: Concurrent Groovy Shared Library syncs on different jobs use same workspace root
I know this issue is old, but I think it's repro'ing for me on Jenkins 2.164.3 with P4 Plugin 1.9.7. The key difference Here is an example pipeline that I'm loading both a global library and a DYNAMIC library repros the error . I don't know if Note that 's relevant. Near the top of my pipeline, I load it DYNAMICALLY loads a library with this snippet: pipeline. {code:java}library 'global-library@now'String stream_name = 'stream_name'String client_name = "jenkins-${env.JOB_NAME}-${stream_name}-library"String library_source = "//depot/${stream_name}/Jenkinsfile/lib/..."library (identifier: stream_name + ' dynamically - loaded- library@now', retriever: legacySCM([$class: 'PerforceScm', credential: 'p4creds',populate: [$class: 'AutoCleanImpl', delete: true, modtime: false, parallel: [ enable: false, minbytes: '1024', minfiles: '1', threads: '4' ], pin: '', quiet: true, replace: true, tidy: false], workspace: [$class: 'ManualWorkspaceImpl', charset: 'none', name: client_name "jenkins-${env.JOB_NAME}-dynamically-loaded-library" ,pinHost: false, spec: [ allwrite: true, clobber: false, compress: false, line: 'LOCAL', locked: false, modtime: false, rmdir: false, streamName: '', view: " ${library_source} // depot/build-library/... //jenkins- ${ client_name env.JOB_NAME } -dynamically-loaded-library /..."]]])) // rest of the pipeline node() { stage('Echo') { echo("If you hit 'Build Now' rapidly enough, a build wiill fail before it even gets here.")}}{ code} This If you hit "Build Now" once, it works great in isolation . But my job is failing intermittently If you rapidly hit it a few times, several builds will fail with this error. It seems to happen most (but not always!) when multiple builds are triggered at the same time. {code:xml}P4 Task: reverting all pending and shelved revisions p4 revert d:\JenkinsHome\jobs\stream_name\workspac___ -p4 revert d:\JenkinsHome\jobs\stream_name\jobs\stream_name -build \workspace_libs\ stream_name dynamically - loaded- library_2/...ERROR: P4: Task Exception: hudson.AbortException: P4JAVA: Error(s):Path 'd:\JenkinsHome\jobs\stream_name\workspace_libs\ stream_name dynamically - loaded- library_2/...' is not under client's root 'd:\JenkinsHome\jobs\stream_name\workspace_libs\ stream_name dynamically - loaded- library'.{code} The global library works fine and never It seems to have like when two builds are run in a problem. The 'stream library' that I dynamically load occasionally throws an error syncing on VERY close timeframe, the master.I can't figure out what logic it uses to plugin will append "_2" to the folder name, nor why it library 's failing to update foldername, but re-uses the old p4 client accordingly workspace . It also seems like a bug that one path ends EDIT: Edited my original comment to be more concise, with "/ a working example . .." while the other does not.
[JIRA] (JENKINS-50975) Concurrent Groovy Shared Library syncs on different jobs use same workspace root
Title: Message Title
Jay Spang edited a comment on JENKINS-50975
Re: Concurrent Groovy Shared Library syncs on different jobs use same workspace root
I know this issue is old, but I think it's repro'ing for me on Jenkins 2.164.3 with P4 Plugin 1.9.7. The key difference is that I'm loading both a global library and a DYNAMIC library. I don't know if that's relevant. Near the top of my pipeline, I load a library with this snippet:{code:java} library 'global-library@now' String stream_name = 'stream_name'String client_name = "jenkins-${env.JOB_NAME}-${stream_name}-library"String library_source = "//depot/${stream_name}/Jenkinsfile/lib/..."library(identifier: stream_name + '-library@now', retriever: legacySCM([$class: 'PerforceScm', credential: 'p4creds',populate: [$class: 'AutoCleanImpl', delete: true, modtime: false, parallel: [enable: false, minbytes: '1024', minfiles: '1', threads: '4'], pin: '', quiet: true, replace: true, tidy: false], workspace: [$class: 'ManualWorkspaceImpl', charset: 'none', name: client_name,pinHost: false, spec: [allwrite: true, clobber: false, compress: false, line: 'LOCAL', locked: false, modtime: false, rmdir: false, streamName: '', view: "${library_source} //${client_name}/..."]]]))// rest of the pipeline{code}This works great in isolation. But my job is failing intermittently with this error. It seems to happen most (but not always!) when multiple builds are triggered at the same time.{code:xml}P4 Task: reverting all pending and shelved revisions p4 revert d:\JenkinsHome\jobs\stream_name\workspac___ -p4 revert d:\JenkinsHome\jobs\stream_name\jobs\stream_name-build\workspace_libs\stream_name-library_2/...ERROR: P4: Task Exception: hudson.AbortException: P4JAVA: Error(s):Path 'd:\JenkinsHome\jobs\stream_name\workspace_libs\stream_name-library_2/...' is not under client's root 'd:\JenkinsHome\jobs\stream_name\workspace_libs\stream_name-library'.{code} The global library works fine and never seems to have a problem. The 'stream library' that I dynamically load occasionally throws an error syncing on the master.I can't figure out what logic it uses to append "_2" to the folder name, nor why it's failing to update the p4 client accordingly. It also seems like a bug that one path ends with "/..." while the other does not.
Add Comment
[JIRA] (JENKINS-50975) Concurrent Groovy Shared Library syncs on different jobs use same workspace root
Title: Message Title
Jay Spang edited a comment on JENKINS-50975
Re: Concurrent Groovy Shared Library syncs on different jobs use same workspace root
I know this issue is old, but I think it's repro'ing for me on Jenkins 2.164.3 with P4 Plugin 1.9.7. The key difference is that I'm loading a DYNAMIC library. I don't know if that's relevant. Near the top of my pipeline, I load a library with this snippet:{code:java}String stream_name = 'stream_name'String client_name = "jenkins-${env.JOB_NAME}-${stream_name}-library"String library_source = "//depot/${stream_name}/Jenkinsfile/lib/..."library(identifier: stream_name + '-library@now', retriever: legacySCM([$class: 'PerforceScm', credential: 'p4creds',populate: [$class: 'AutoCleanImpl', delete: true, modtime: false, parallel: [enable: false, minbytes: '1024', minfiles: '1', threads: '4'], pin: '', quiet: true, replace: true, tidy: false], workspace: [$class: 'ManualWorkspaceImpl', charset: 'none', name: client_name,pinHost: false, spec: [allwrite: true, clobber: false, compress: false, line: 'LOCAL', locked: false, modtime: false, rmdir: false, streamName: '', view: "${library_source} //${client_name}/..."]]]))// rest of the pipeline{code}This works great in isolation. But my job is failing intermittently with this error. It seems to happen most (but not always!) when multiple builds are triggered at the same time.{code :xml }P4 Task: reverting all pending and shelved revisions p4 revert d:\JenkinsHome\jobs\stream_name\workspac___ -p4 revert d:\JenkinsHome\jobs\stream_name\jobs\stream_name-build\workspace_libs\stream_name-library_2/... ERROR: P4: Task Exception: hudson.AbortException: P4JAVA: Error(s): Path 'd:\JenkinsHome\jobs\stream_name\workspace_libs\stream_name-library_2/...' is not under client's root 'd:\JenkinsHome\jobs\stream_name\workspace_libs\stream_name-library'.{code}I can't figure out what logic it uses to append "_2" to the folder name, nor why it's failing to update the p4 client accordingly. It also seems like a bug that one path ends with "/..." while the other does not.
Add Comment
[JIRA] (JENKINS-50975) Concurrent Groovy Shared Library syncs on different jobs use same workspace root
Title: Message Title
Jay Spang reopened an issue
I know this issue is old, but I think it's repro'ing for me on Jenkins 2.164.3 with P4 Plugin 1.9.7. The key difference is that I'm loading a DYNAMIC library. I don't know if that's relevant. Near the top of my pipeline, I load a library with this snippet:
String stream_name = 'stream_name'
String client_name = "jenkins-${env.JOB_NAME}-${stream_name}-library"
String library_source = "//depot/${stream_name}/Jenkinsfile/lib/..."
library(
identifier: stream_name + '-library@now',
retriever: legacySCM(
[
$class: 'PerforceScm', credential: 'p4creds',
populate: [
$class: 'AutoCleanImpl',
delete: true,
modtime: false,
parallel: [
enable: false,
minbytes: '1024',
minfiles: '1',
threads: '4'
],
pin: '',
quiet: true,
replace: true,
tidy: false
],
workspace: [
$class: 'ManualWorkspaceImpl',
charset: 'none',
name: client_name,
pinHost: false,
spec: [
allwrite: true,
clobber: false,
compress: false,
line: 'LOCAL',
locked: false,
modtime: false,
rmdir: false,
streamName: '',
view: "${library_source} //${client_name}/..."
]
]
]
)
)
// rest of the pipeline
This works great in isolation. But my job is failing intermittently with this error. It seems to happen most (but not always!) when multiple builds are triggered at the same time.
P4 Task: reverting all pending and shelved revisions.
... p4 revert d:\JenkinsHome\jobs\stream_name\workspac___
-
p4 revert d:\JenkinsHome\jobs\stream_name\jobs\stream_name-build\workspace_libs\stream_name-library_2/...
Path 'd:\JenkinsHome\jobs\stream_name\workspace_libs\stream_name-library_2/...' is not under client's root 'd:\JenkinsHome\jobs\stream_name\workspace_libs\stream_name-library'.
I can't figure out what logic it uses to append "_2" to the folder name, nor why it's failing to update the p4 client accordingly. It also seems like a bug that one path ends with "/..." while the other does not.
Jenkins / JENKINS-50975
Concurrent Groovy Shared Library syncs on different jobs use same workspace root
[JIRA] (JENKINS-51552) Cannot replay pipelines - files are read-only
Title: Message Title Jay Spang commented on JENKINS-51552 Re: Cannot replay pipelines - files are read-only What happens if you changer `allwrite: false` in the client definition to be true? 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.190940.1527360591000.10319.1565217180205%40Atlassian.JIRA.
[JIRA] (JENKINS-55737) "No polling baseline - Changes found" causing runaway polling
Title: Message Title Jay Spang commented on JENKINS-55737 Re: "No polling baseline - Changes found" causing runaway polling This seems to be fixed now. It has not reprod since 1.9.7 was installed. 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.197010.1548200108000.23791.1559931120133%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55737) "No polling baseline - Changes found" causing runaway polling
Title: Message Title Jay Spang created an issue Jenkins / JENKINS-55737 "No polling baseline - Changes found" causing runaway polling Issue Type: Bug Assignee: Unassigned Components: p4-plugin Created: 2019-01-22 23:35 Environment: Jenkins 2.138.3 (Windows on AWS EC2, both Master and Nodes) Blue Ocean 1.8.4 P4 Plugin: 1.9.2 Priority: Major Reporter: Jay Spang I have a build job that polls Perforce for changes every 5 minutes. Occasionally, with (seemingly) no changes, Jenkins still start building the project every time it polls, regardless of whether there are new checkins or not. I call this "runaway polling". If I disable the build and then re-enable it after everything has finished, the runaway polling stops. However, this quickly overwhelms our Jenkins instance, as we allow concurrent builds. In the Perforce polling log, this message correlates to the problem. I see it in every "runaway polling" build: no polling baseline in D:\workspace\jobName on NODE_NAME Done. Took 7.2 sec Changes found Neither the node nor its p4 client are new, both have been in place for days. There's no indication what command is being run to check the "baseline", nor is there any information on why it starts failing, so this is very difficult to troubleshoot.
[JIRA] (JENKINS-45455) Restarting stages
Title: Message Title Jay Spang commented on JENKINS-45455 Re: Restarting stages Jan Hoppe Andrew Bayer please update this thread if you created a ticket to disable stage restart. We desperately need this. This feature does not work at all with my pipelines (it does not run on the same node as the original run), so it's generating false positives and wreaking havoc with my customers. I'm considering implementing some custom CSS to hide the silly thing before it causes us any more grief! 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] [core] (JENKINS-13253) Slave connection reset issues since 1.456
Jay Spang commented on JENKINS-13253 Slave connection reset issues since 1.456 I'm also seeing this same issue. Master: Jenkins 1.537 (Win2012) Slave: Win7 using JNLP It doesn't afflict just one slave. I have a pool of 10 identical slaves and I would guess that I get this error maybe 2-3 times a day across different slaves (causing jobs to fail ). 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/groups/opt_out.
[JIRA] [perforce] (JENKINS-10686) Polling on slaves can hang
Jay Spang commented on JENKINS-10686 Polling on slaves can hang Can you clarify how to get around this then? I do have the latest version of the Perforce plugin (1.3.26) The master is Windows, and uses c:\p4\p4.exe The slave is OSX, and uses /usr/bin/p4 I have the job configured to run on the OSX slave and use /usr/bin/p4 as the executable. If I check "Poll only on master", the job tries to poll by running "/usr/bin/p4" on the Windows master, which obviously fails. If I change the Perforce executable in the job to c:\p4\p4.exe, Polling will work again, but the job immediately fails to sync the workspace (because it tries to run c:\p4\p4.exe on the OSX slave). 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/groups/opt_out.
[JIRA] [buildgraph-view] (JENKINS-19470) Build Graph not displaying
Jay Spang commented on JENKINS-19470 Build Graph not displaying Repro'ing for me on Jenkins 1.5.37 (Win2012 Server), BuildFlow 0.10, BuildGraphView 1.1.1. I don't know what event causes the graphs to disappear, but they disappear after a couple of hours whether I've restarted Jenkins or not (I just checked and a build I ran 2h8m ago has already lost its graph). 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/groups/opt_out.
[JIRA] [perforce] (JENKINS-20493) Plugin send encrypted password, login denied
Jay Spang commented on JENKINS-20493 Plugin send encrypted password, login denied Can you provide a source for the Perforce trigger bug? I'm seeing this issue too (my Perforce ticket is shown on the Console output, so anyone with access to the logs can see the ticket) so I'm keen to get to the bottom of this and resolve it if possible. 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/groups/opt_out.
