Leverage Perforce Workspaces with Bamboo
My employer uses Perforce and Bamboo in our continuous integration environment and we have an ongoing problem with Perforce workspaces: they are a pain to maintain!
Our environment is set up as follows:
- 1 Perforce server, 100 depots, 10 projects in the depot. Sometimes projects use code from multiple warehouses.
- Developers maintain their own workspaces for their local machines.
- Workspaces are created for Bamboo assembly plans.
- Bamboo workspaces include only the paths needed to create the project.
- Often, a single build plan has multiple workspaces due to the interaction between Bamboo and Perforce. Parallel jobs cannot share the same workspace because Bamboo sets the root of the workspace to match the build agent.
- Build plan sections also get their own workspaces.
Anytime developers want to add space to a workspace, they need to update many workspaces. It's annoying and easy to mess up.
Is there a way to reduce the number of workspaces? Could changes be made to the way we structure things to make it easier to maintain?
source to share
The simplest solution would be to use threads, which are essentially dynamic workspace templates.
A stream defines a set of depot paths, and a workspace can be associated with a stream rather than a manually defined view. When a stream is refreshed, all workspaces associated with it are instantly refreshed to match. Therefore, if your projects have been defined as threads, the developer updating the project will trigger automatic updates in all build workspaces that point to the same thread.
An alternative is to designate a main client workspace for each project used as a template and use the "p4 client -t" command to copy your view - the trick is that this won't happen automatically as it is for streaming workspaces, so you probably want to tweak your automation in the build system to make sure its workspace is up to date.
source to share
Parallel jobs cannot share the same workspace because Bamboo sets the workspace root to the build agent.
They can share the same workspace, but there is a tradeoff - ease of assembly (single workspace) versus build time (forced sync).
The "easy to build" solution (which seems to be what you are asking for)
Bamboo syncs customer BOM from depot (build area). the spec file looks like this:
Host: **<leaveThisBlank>**
Description: Blah
Root: /some/default/ws/<wsName>
AltRoots: D:/01/xml-data/build-dir
D:/02/xml-data/build-dir
D:/03/xml-data/build-dir
Options: $yourOptions rmdir
SubmitOptions: nosubmitunchanged
LineEnd: local
View:
//depot/... //$wsName/depot/...
The above file assumes you have 3 agents (numbered 1-3)
Set BuildRoot for bamboo agent in $ BAMBOO-HOME / bamboo.cfg.xml as D: / $ agentNumber / xml-data / build-dir
Build is done by client p4 -i & lt; / path / to / spec / file
The build agent looks for the default root, doesn't find it, looks for the first altroot, doesn't find it again, looks for the second altroot, finds it and then ... well, then you'll need to do a FORCE sync.
(Perforce keeps track of the most recent changelog it served in the db.have list on the server, if the most recent build agent was # 03 and now it runs at # 02, you will only get files that were different between the last changelog #) so FORCE is the only answer.
Build plan branches also get their own workspaces.
Their bamboo key is different, so they will be in a different directory D: / $ agentNumber / xml-data / build-dir / $ PROJECT- (branch) PLAN-JOB
source to share