[JIRA] [p4] (JENKINS-24624) Support for shared workspaces

2014-10-28 Thread morne.joub...@u-blox.com (JIRA)














































Morne Joubert
 commented on  JENKINS-24624


Support for shared workspaces















I have configure the project to behave as follows

_MA_SW_ci_tools${EXECUTOR_NUMBER}jenkins_p4${SITE}-${NODE_NAME}

where _MA_SW_ci_tools is a reference to a unique P4 stream.

It seems to work



























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.


[JIRA] [p4] (JENKINS-24624) Support for shared workspaces

2014-10-28 Thread pal...@perforce.com (JIRA)














































Paul Allen
 commented on  JENKINS-24624


Support for shared workspaces















It may be possible to share workspaces using the client -s flag (with -t or -S).  The -s flag would switch the view and a sync should only fetch the differences.  This would help with the storage requirements for a workspace as there is only one root required per executor.

How to implemented under Jenkins is going to need some careful thought.



























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.


[JIRA] [p4] (JENKINS-24624) Support for shared workspaces

2014-10-28 Thread morne.joub...@u-blox.com (JIRA)














































Morne Joubert
 commented on  JENKINS-24624


Support for shared workspaces















having a workspace per executor is not a problem so far.

So if i have a slave with 4 executors and 50 different jobs all using the same stream then i only have 4 jenkins workspaces and 4 P4 client specs.

I assume Jenkins keep track of the last synced version outside of Perforce ? I can't see how it would work otherwise



























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.


[JIRA] [p4] (JENKINS-24624) Support for shared workspaces

2014-09-08 Thread morne.joub...@u-blox.com (JIRA)














































Morne Joubert
 created  JENKINS-24624


Support for shared workspaces















Issue Type:


New Feature



Assignee:


Unassigned


Components:


p4



Created:


08/Sep/14 9:45 AM



Description:


I have recently joined a company that is using Jenkins (i used to manage TeamCity in an enterprise environment for 250 engineers) and am having problems seeing how Jenkins scales using Perforce.

My problem is as follows:

Setup: 
1 Slave with 1 executor
10 different builds all using the same stream

Current Jenkins behavior (to allow the Workspace browser to work) is to sync 10 different workspaces (all with the same code) and create 10 different client specs in perforce.

Now take a slave with 16 executors.
We now have 16*10 copies of exactly the same stream source code on the slave and 16*10 client specs in perforce.

Now scale it up to 50 different builds using 3 different streams with many slaves and the whole system just doesn't scale well from an IT storage and perforce access point of view

What i was hoping to achieve (and this is how TeamCity and ElectricCommander does it) it to be able to share workspaces between builds.

If we created workspaces/clientspecs PER EXECUTOR then 2 builds can't use the source code at the same time.
So if a slave had 16 executors then there would only be 16 clientspecs and 16 workspaces for each stream and the builds won't clash since each executor can only do one thing at a time.

I am happy to loose the Workspace browser (that we never use) since this won't be valid anymore.

For this to work i would expect the change history tracking can't be stored on the perforce server side since the workspace/client spec is now shared so am not sure if this can actually be solved.

Any suggestions on how this can be achieved ?
This would be a big opportunity for Perforce to get themselves into Jenkins use for enterprise use. (that TeamCity and ElectricCommander has already done)








Project:


Jenkins



Priority:


Major



Reporter:


Morne Joubert

























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.