CODEWITHSUNDEEP
continuous-integrationperforcebamboo
sourcenouveau
sourcenouveau

Reputation: 30534

Using Perforce workspaces effectively with Bamboo

My employer uses Perforce and Bamboo in our continuous integration environment and we have a persistent problem with Perforce workspaces: they are a pain to maintain!

Our environment is set up like this:

Any time developers want to add a location to the workspace they need to update many workspaces. It's annoying and easy to mess up.

Is there any way to reduce the number of workspaces? Are there changes we can make to the way we structure things to make maintenance easier?

Upvotes: 3

Views: 723

Answers (2)

A...
A...

Reputation: 43

Parallel jobs cannot use the same workspace, since Bamboo sets the workspace root to match the build agent.

They can use the same workspace, but there's a tradeoff - build simplicity (single workspace) compared to build time (forced sync).

A 'build simplicity' solution (which seems to be what you're asking for)

Bamboo syncs a client spec from the depot (build area). the spec file looks like :

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 the BuildRoot on the bamboo agent in $BAMBOO-HOME/bamboo.cfg.xml to be D:/$agentNumber/xml-data/build-dir

The build performs a p4 client -i < /path/to/spec/file

The build agent will look for the default root, not find it, look for the first altroot, again not find it, look for the second altroot, find it and then ... well, then you'll have to FORCE the sync.

(Perforce keeps track of the most recent changelist it served up in a db.have list on the server, if the build's most recent agent was #03, and now it's running on #02, you'll only get the files that differed between the last changelist#) so a FORCE is the only answer.

Build plan branches also get their own workspaces.

Their bamboo key is different, so they'll be in a diff't subdir off D:/$agentNumber/xml-data/build-dir/$PROJECT-(branch)PLAN-JOB

Upvotes: 0

Samwise
Samwise

Reputation: 71517

The simplest solution would be to use streams, which are essentially dynamic workspace templates.

A stream defines a set of depot paths, and a workspace can be linked to a stream rather than having a manually specified view. When a stream is updated, all workspaces that are linked to it are instantly updated to match. So if your projects were defined as streams, a developer updating the project would trigger automatic updates in all of the build workspaces that point to the same stream.

The manual alternative is to designate a master client workspace for each project to use as a template, and use the "p4 client -t" command to copy its view -- the trick is that this won't happen automatically as it does for stream workspaces, so you'd probably want to set up your own automation on the build system to make sure its workspace is up to date.

Upvotes: 2

Related Questions