Perforce configuration for Swarm
Now that you have a configured instance of Swarm, the last piece is to configure Perforce to tell Swarm about interesting events. This is accomplished through the use of triggers.
Tip
For more information about Perforce triggers, see:
Using Perforce triggers to push events to Swarm
-
Use the following Swarm trigger script to push Perforce events into Swarm. For a Perforce service installed on Linux:
p4-bin/scripts/swarm-trigger.sh
For a Perforce service installed on Windows, use the following Swarm trigger script:
p4-bin/scripts/swarm-trigger.vbs
-
Copy the script above to your Perforce server machine so that it can be called from a Perforce trigger.
-
Modify the script to set the
SWARM_HOST
variable appropriately. -
Modify the script to set the
SWARM_TOKEN
variable appropriately. Use the API token established in the “Establish trigger token” section. -
Ensure that the script has execute permissions. For Linux installations:
$ chmod +x swarm-trigger.sh
-
For a Linux-based Perforce service (see below for a Windows-based Perforce service):
As a Perforce user with super privileges, edit the Perforce trigger table by running the p4 triggers command and adding the following lines:
swarm.job form-commit job "%quote%/path/to/swarm-trigger.sh%quote% -t job -v %formname%" swarm.user form-commit user "%quote%/path/to/swarm-trigger.sh%quote% -t user -v %formname%" swarm.userdel form-delete user "%quote%/path/to/swarm-trigger.sh%quote% -t userdel -v %formname%" swarm.group form-commit group "%quote%/path/to/swarm-trigger.sh%quote% -t group -v %formname%" swarm.groupdel form-delete group "%quote%/path/to/swarm-trigger.sh%quote% -t groupdel -v %formname%" swarm.change form-commit change "%quote%/path/to/swarm-trigger.sh%quote% -t change -v %formname%" swarm.shelve shelve-commit //... "%quote%/path/to/swarm-trigger.sh%quote% -t shelve -v %change%" swarm.commit change-commit //... "%quote%/path/to/swarm-trigger.sh%quote% -t commit -v %change%" #swarm.enforce.1 change-submit //DEPOT_PATH1/... "%quote%/web/apps/swarm/p4-bin/scripts/swarm-trigger.sh%quote% -t enforce -v %change% -p %serverport%" #swarm.enforce.2 change-submit //DEPOT_PATH2/... "%quote%/web/apps/swarm/p4-bin/scripts/swarm-trigger.sh%quote% -t enforce -v %change% -p %serverport%" #swarm.strict.1 change-content //DEPOT_PATH1/... "%quote%/web/apps/swarm/p4-bin/scripts/swarm-trigger.sh%quote% -t strict -v %change% -p %serverport%" #swarm.strict.2 change-content //DEPOT_PATH2/... "%quote%/web/apps/swarm/p4-bin/scripts/swarm-trigger.sh%quote% -t strict -v %change% -p %serverport%"
Note
The last four trigger lines are commented out as they are optional, and require that the
DEPOT_PATH1
andDEPOT_PATH2
values are configured appropriately.-
The first two lines configure the enforce feature, which rejects any submitted changes that are not tied to an approved review.
-
The second two lines configure the strict feature, which rejects any submitted changes when the contents of the changelist do not match the contents of its associated approved review.
If you need to apply enforce or strict to more depot paths, copy the lines and tweak their depot path as necessary.
For a Windows-based Perforce service (see above for a Linux-based Perforce service):
As a Perforce user with super privileges, edit the Perforce trigger table by running the
p4 triggers
command and adding the following lines:swarm.job form-commit job "C:\windows\system32\cscript.exe /nologo %quote%C:\path\to\swarm-trigger.vbs%quote% /type:job /value:%formname%" swarm.user form-commit user "C:\windows\system32\cscript.exe /nologo %quote%C:\path\to\swarm-trigger.vbs%quote% /type:user /value:%formname%" swarm.userdel form-delete user "C:\windows\system32\cscript.exe /nologo %quote%C:\path\to\swarm-trigger.vbs%quote% /type:userdel /value:%formname%" swarm.group form-commit group "C:\windows\system32\cscript.exe /nologo %quote%C:\path\to\swarm-trigger.vbs%quote% /type:group /value:%formname%" swarm.groupdel form-delete group "C:\windows\system32\cscript.exe /nologo %quote%C:\path\to\swarm-trigger.vbs%quote% /type:groupdel /value:%formname%" swarm.change form-commit change "C:\windows\system32\cscript.exe /nologo %quote%C:\path\to\swarm-trigger.vbs%quote% /type:change /value:%formname%" swarm.shelve shelve-commit //... "C:\windows\system32\cscript.exe /nologo %quote%C:\path\to\swarm-trigger.vbs%quote% /type:shelve /value:%change%" swarm.commit change-commit //... "C:\windows\system32\cscript.exe /nologo %quote%C:\path\to\swarm-trigger.vbs%quote% /type:commit /value:%change%"
Note
Update the trigger script paths in each line above to reflect the actual script path on your Perforce server.
The enforce and strict features available for a Linux-based Perforce service are not currently available for a Windows-based Perforce service.
Warning!
The use of
%quote%
is not supported on 2010.2 servers (it is harmless though); if you are using this version, ensure that you do not have any spaces in the script's path.Warning!
For a Perforce service on Windows, installation of the triggers may cause a security warning dialog to appear when curl.exe executes:
If this occurs, the triggers hang, creating zombie cscript processes.
To resolve this, context-click curl.exe, choose , and click .
-
Hiding Swarm storage from regular users
Swarm information storage uses the Perforce service's keys facility. By default, users with list-level access can search keys and potentially obtain information they would not otherwise have access to, and users with review-level access can write or modify keys potentially corrupting or destroying data.
We recommend that you set the dm.keys.hide
configurable
to 2
to require admin-level access
for searching and modifying keys. Note that dm.keys.hide
is available in Perforce server versions 2013.1 and newer.
When dm.keys.hide
is set to 2
, both
the p4 keys and p4 key commands require admin-level
access in the Perforce service. When dm.keys.hide
is
set to 1
, only the p4 keys command requires
admin-level access in the Perforce service. When
dm.keys.hide
is set to 1
, or is not
set, users who know (or can deduce) key names can read values (if they
have list-level access) or write values (if they have
review-level access) with the p4 key command.
To set dm.keys.hide
:
$ p4 configure set dm.keys.hide=2
To confirm the current value of dm.keys.hide
:
$ p4 configure show dm.keys.hide
To unset dm.keys.hide
:
$ p4 configure unset dm.keys.hide