|
||||||||
|
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 [email protected].
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