Merging multiple workflows
When a changelist includes files that span multiple projects or branches, P4 Code Review merges the applicable workflows and applies the most restrictive rule for each workflow setting. All workflow tests defined by the merged workflows are run. If multiple workflows include the same test, it is executed only once.
On this page:
Example 1: Changelist spanning multiple unrelated projects
Projects involved:
-
Project A:
//depot/jam/lib/... -
Project B:
//depot/jam/docs/... -
Project C:
//depot/common/src/...
Changelist 1234 contains:
//depot/jam/lib/tests/checkLoad.sh//depot/jam/docs/basics.workflow.html//depot/common/src/index.html
Because the files span all three project locations, the workflow for Changelist 1234 is formed by merging the three project workflows. For each rule, the most restrictive setting is selected. All associated workflow tests are run.
Merged workflow result
The three workflows are combined and the most restrictive workflow rules are used for the changelist. All of the tests associated with the three workflows are run but Smoke Test B from Project A and Project B is only run once.
| Workflow source | Changelist without a review | Changelist with a review | Update review in end state? | Count up-votes from | Auto-approve reviews | Workflow Tests |
|---|---|---|---|---|---|---|
| Project A workflow | Allow | Reject unless approved | Allow | Anyone | Based on vote count | Smoke Test A |
| Project B workflow | Allow | Reject unless approved | Reject | Members | Never | Smoke Test B |
| Project C workflow | Create a review | Allow | Allow | Anyone | Based on vote count |
Smoke Test B Smoke Test C |
| Changelist 1234 workflow | Create a review | Reject unless approved | Reject | Members | Never |
Smoke Test A Smoke Test B Smoke Test C |
Example 2: Changelist spanning a project and its branch
Projects involved:
-
Project M:
//depot/thirdparty/lib/... -
Project N:
//depot/thirdparty/lib/tests/... -
Project branch N-1:
-
//depot/projectN/... -
//depot/thirdparty/lib/...
-
Changelist 6789 contains:
-
//depot/thirdparty/lib/tests/checkReturns.sh -
//depot/projectN/src/index.html -
//depot/projectN/tests/pageLoadTest.php
The changelist files span all three locations so the changelist is subject to the combined workflow rules for the three locations. The most restrictive workflow is used for the changelist.
This means Project branch N‑1 includes and overrides the workflow for Project N.
Therefore, Project N’s workflow is ignored, and the changelist merges only:
-
Project M workflow
-
Project branch N‑1 workflow
Merged workflow result
| Workflow source | Changelist without a review | Changelist with a review | Update review in end state? | Count up-votes from | Auto-approve reviews | Workflow Tests |
|---|---|---|---|---|---|---|
| Project M workflow | Create a review | Reject unless approved | Allow | Anyone | Never | Smoke Test M |
| Project N workflow | Reject | Reject unless approved | Reject | Members | Never | Smoke Test N |
| Project branch N-1 workflow | Create a review | Allow | Allow | Anyone | Based on vote count | Smoke Test N-1 |
| Changelist 6789 workflow | Create a review | Reject unless approved | Allow | Anyone | Never |
Smoke Test M Smoke Test N-1 |
In summary, the rules for Project N are ignored because Project branch N-1 is a branch of Project N and it has its own workflow rules.
This is why the merged results are:
-
Changelist without a review = Create review
-
On update of a review in an end state = Allow
-
Count votes up from = Anyone
Example 3: Changelist spanning multiple projects and global workflow rules
Projects involved:
-
Project X:
//depot/main/product/... -
Project Y:
//depot/main/product/docs/... -
Global workflow rules (administrator‑defined)
Changelist 3456 contains:
-
//depot/main/product/tests/fileSelector.sh -
/depot/main/product/docs/admin.html -
//depot/projectN/tests/pageLoadTest.php
The changelist files span both locations so the changelist is subject to the combined workflow rules for the two locations, and the Global workflow rules set by the administrator.
Merged workflow result
| Workflow source | Changelist without a review | Changelist with a review | Update review in end state? | Count up-votes from | Auto-approve reviews | Workflow Tests |
|---|---|---|---|---|---|---|
| Project X workflow | Create a review | Allow | Allow | Anyone | Based on vote count | Smoke Test X |
| Project Y workflow | Reject | Allow | Reject | Anyone | Based on vote count | Smoke Test Y |
| Global workflow rules | Create a review (Enforce on) | Reject unless approved (Enforce off) | Allow (Enforce on) | Members (Enforce on) | Never (Enforce off) |
Global Smoke Test Global Full Test |
| Changelist 3456 workflow | Reject | Allow | Reject | Members | Based on vote count |
Smoke Test X Smoke Test Y Global Smoke Test Global Full Test |
The global workflow rule mode determines how the global rule interacts with the workflow rules. For more information about global rule modes, see Workflow basics.
How global rules are applied
-
Enforce off:
The global rule is only used if no project/branch rule exists.
If the project/branch has an associated workflow, the global rule setting is ignored. This is why:
-
Changelist with a review = Allow
-
Automatically approve reviews = Based on vote count
-
-
Enforce on:
The global rule participates in merging, and the most restrictive setting is used. This is why:
-
Changelist without a review = Reject
-
On Update of a review in an end state = Reject
-
Count votes up from = Members
-
Moderators can also influence final workflow behavior. If any project/branch has a moderator assigned, reviews cannot be automatically approved. For more information, see Moderators.