KBEC-00103 - Encountering merge conflicts during Preflights when using auto-commit

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.

This article is part of our Knowledge Base and is provided for guidance-based purposes only. The solutions or workarounds described here are not officially supported by CloudBees and may not be applicable in all environments. Use at your own discretion, and test changes in a safe environment before applying them to production systems.