Description
If you use Perforce, you may encounter a classic merge case when you use auto-commit. Two developers check out file 'foo.c' and make modifications. Developer #1 performs a successful preflight and checks in foo.c. Next, developer #2 starts a preflight. By default, will dev #2’s preflight fail because his version of foo.c is out of date? Or will the preflight ignore the merge situation? Or will it try to auto-resolve the merge?
Solution
It is configurable.
Near the top of the Perforce client driver script (stored in /server/ec_preflight/clientDrivers/perforce), the following code exists:
# Policy variables: $::gDieOnNewCheckins = 0; $::gDieOnWorkspaceChanges = 0; $::gDieOnFileChanges = 0;
-
If you set gDieOnNewCheckins to 1, then if there are any check-ins at all between launching the preflight and the auto-commit stage, CloudBees CD (CloudBees Flow) exits. This is effectively serial preflights.
-
If you set gDieOnWorkspaceChanges to 1, then if there are any check-ins within the user’s client spec between launch and auto-commit, CloudBees CD (CloudBees Flow) exits.
-
If you set gDieOnFileChanges to 1, then if there are any check-ins to the user’s opened files between launch and auto-commit, CloudBees CD (CloudBees Flow) exits.
-
If all three are set to 0 (what CloudBees CD (CloudBees Flow) sets it to by default), then CloudBees CD (CloudBees Flow) tries to sync and auto-resolve any conflicts before checking in. If there are conflicts that cannot be auto-resolved, the user will be asked to manually resolve the conflicts and retry the preflight.