Server Policies Resolution
Key factors for resolving server policies of a project include the following:
• When the policies of a particular project are evaluated, the configuration path is used to traverse the project hierarchy or tree using the top-down approach. The policy resolution traversal starts at the top-level project and traverses to the subprojects by following the configuration path.
For example, consider the following project:
/top-level1/subproject/project.pj
The policy evaluations are performed in the following order:
1. Global policy settings
2. Global policy settings for /top-level1/project.pj (if they exist)
3. Policy settings for /top-level1/subproject/project.pj (if they exist)
The subsequent policy settings override the previous policy settings.
It is important to note that while the traversal is based on the configuration path, the actual evaluation of the project is based on the canonical (and variant, if applicable) path of the project. This is important when the project encountered in the hierarchy is either a shared project or a moved project, and thus its configuration is different from its canonical location. For example, consider the following project:
/top-level2/shared-subproject/project.pj
where
shared-subproject is shared from /top-level1/subproject/project.pj from the previous example.
The policy evaluations are performed in the following order:
1. Global policy settings
2. Global policy settings for /top-level2/project.pj
3. Policy settings for /top-level1/subproject/project.pj, which is the canonical location of /top-level2/shared-subproject/project.pj
• As the policies are evaluated in the hierarchical order, a policy for a subproject overrides the policy set for a project higher in the hierarchy. To avoid a subproject policy setting overriding the policy set at a higher level, the policy at the higher level can be locked. Once a locked policy is encountered during hierarchy navigation, the policy setting of the subproject no longer overrides the locked policy.
• When evaluating server policies for variant projects, Integrity Lifecycle Manager searches the mainline also along with the variant paths.
• Integrity Lifecycle Manager consults the Development Path global policy only when the configuration path of the project includes jump to the variant hierarchy occurring from the top-level project. If a jump to the variant hierarchy occurs at a subproject in configuration paths, Integrity Lifecycle Manager does not consult the corresponding Development Path global policy.