|
||||||||
|
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.
I am running into this problem as well. The reason I am trying to have one workspace shared across multiple jobs is due to the size of the particular depot. We can't get enough space on a slave machine to have multiple stored versions of the same code/content/art. P4 Streams would make our lives easier, but our release cadence prevents that work from getting done.
What I will do in the meantime is set up a 'starter' project for the branch that updates the client workspace, then hand control off to the actual project the user meant to run. I would like to see a fix for this, we're limiting executor access to those directories by branch currently, so I am not worried about concurrent runs on the same slave node.
He's a repro:
in 1 job, in 1 workspace, sync a file
Check in a change to that file
in a separate job referencing the same workspace, trigger a build that syncs
You will be able to observe the have entry for that file updates, but the file on disk will remain at rev 1