[#BAM-2363] Resolve perforce source directory issue

Bamboo

Resolve perforce source directory issue

Created: 12/Mar/08 12:43 AM Updated: 01/Apr/08 07:14 PM

Component/s:

None

Affects Version/s:

None

Fix Version/s:

2.0 beta 6, 2.0

Time Tracking:

Original Estimate:

Not Specified

Remaining Estimate:

0 minutes

Time Spent:

1 day, 3 hours

Internal Priority:

2. High

Description

« Hide

We changed perforce to set the source code directory to the plans build-dir folder as opposed to using the root defined in perforce.

The reasons for this change are:

The reason the changes were made initially was to make it easier for you to run distributed builds. The benefit of this is that a single plan can be run on different remote agents and different machines using the one client file. You don't have to worry about ensuring that the workspace root exists exactly the same on all of these boxes, Bamboo will look after it all for you. It also mean that the build data is stored in your bamboo home rather than elsewhere on the system (where there may be permissioning issues). There were also some issues with caching the source repository that we were trying to resolve.

The problem is that there now needs to be one client per plan in case they build at the same time and alter the dir. Some customers have expressed that this is not a good idea.

see http://forums.atlassian.com/thread.jspa?threadID=24094

Alternatives:

Switch it back to the way it was (just using perforce's definition)
Provide a toggle - the user can pick the old way or the new way

Concerns

The caching source dir is not necessarily needed at this point in time as the build process has changed
What are the consequences if it ever fails to get the client root
Can only set 2 alternate roots - (this functionality hasn't been tested yet either)
If there is the option the user will have to ensure that he doesn't have 1 client set to manage on one plan and not manage on another

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Scott Marshall added a comment - 12/Mar/08 06:32 PM

I am not sure how the old way works but what could work for me would be the ability to define a single client workspace with a known root. Lets say c:\p4builds. I would then define the mappings in the depot for this client that could be built on a box. I would assume this client would only be used on a single build box. Then in Bamboo for each build plan I could reference this client AND the intended depot views that I need for the plan. This would tell the plan which depot paths to watch for changes and which paths to sync when a build takes place. I would like the ability to exclude some paths since a change on them should not trigger a build. I guess the key to this strategy is that the plan needs to pay attention to the mappings defined in the client rather than just the client name itself. Hope this helps as you think about this issue.

Thanks,

-Scott

[ Permlink | « Hide ]

Brydie McCoy [Atlassian] added a comment - 12/Mar/08 11:17 PM

Hi Scott,

Thanks for that, that is in fact the way the 'old way' worked.

Cheers,
Brydie

[ Permlink | « Hide ]

Brydie McCoy [Atlassian] added a comment - 17/Mar/08 06:37 PM

We have decided to go for the toggle option. This means that users can choose whether or not they want Bamboo to manage their workspace. If it is managed, Bamboo will set the client root, if not managed, Bamboo will retrieve the set client root from perforce.

Better error handling has been added in case the client root can not be found, and the client root is no longer cached (as it was in 1.2.x) as it is no longer need for change detection.

Unfortunately alternate roots are not working at the moment (see ~~BAM-2377~~) so if your workspace is not managed you will need to ensure that the main client root exists on all agents that the plan will build on.