Binding workspaces to the build farm replica
At this point, there should be two servers in operation:
- a master server named
master
, with a server ID of master-1666 - a
build-server
replica namedbuildfarm1
, with a server ID of builder-1667
-
Bind client workspaces to the build farm server.
Because this server is configured to offer the
build-server
service, it maintains its own local copy of the list of client workspaces (db.domain
anddb.view.rp
) and their respective have lists (db.have.rp
).On the replica server, create a client workspace with p4 client:
$ p4 -c build0001 -p builder:1667 client build0001
When creating a new workspace on the build farm replica, you must ensure that your current client workspace has a ServerID that matches the ServerID required by
builder:1667
. Because workspacebuild0001
does not yet exist, you must manually specifybuild0001
as the current client workspace with the-c clientname
option and simultaneously supplybuild0001
as the argument to thep4 client
command. See the Support Knowledgebase article on "Build Farm Client Management".When the
p4 client
form appears, set theServerID:
field tobuilder-1667
. If the ServerID is not set manually, it will be set automatically when the form is saved. -
Sync the bound workspace.
Because the client workspace
build0001
is bound tobuilder-1667
, users on the master server are unaffected. However, users on the build farm server are not only able to edit its specification, they are able to sync it:$ export P4PORT=builder:1667 $ export P4CLIENT=build0001 $ p4 sync
The replica’s have list is updated, and does not propagate back to the master. Users of the master server are unaffected.
In a real-world scenario:
- your organization’s build engineers would
re-configure your site’s build system to use the new server by resetting
their
P4PORT
to point directly at the build farm server. Even in an environment in which continuous integration and automated build tools create a client workspace (and sync it) for every change submitted to the master server, performance on the master would be unaffected. - performance on the master is likely to improve for all users because of the reduction of read and write operations on the master server’s database.
If there are database tables that you know your build farm replica does
not require, consider using the -F
and -T
filter options to p4 pull. Also consider specifying
the ArchiveDataFilter:
, RevisionDataFilter:
and
ClientDataFilter:
fields of the replica’s p4
server
form.
If your automation load exceeds the capacity of a single machine, you can configure any number of additional build farm servers.
Your search for returned result(s).