Fix Branched-Based Review Policies Doc

[cghyzel]

• Added Branch Based Polices to Branch Management Automations. The original Branch-Based Policies section is still located under Review Assignment Automations; it is just referenced by the Branch Management Automations section.
• Fixed missing branch[*].reviewers property in docs/downloads/automation-library/standard/review-assignment/review_target_branch.cm
• Reformatted docs/downloads/automation-library/standard/review-assignment/review_source_branch.cm & docs/downloads/automation-library/standard/review-assignment/review_target_branch.cm so that branch properties are in alphabetical order, which is also the order of reference to the properties by the gitstream automation script. This should improve readability.

[gitstream-cm[bot]]

A screenshot of the relevant part of docs after the changes is a life saver 🛟

[gitstream-cm[bot]]

✨gitStream Describe PR ✨

The changes in this pull request include:

1. Documentation Update:

   • In the README file for branch management automation, the section titled "Assign Reviewers Based on Target Branch" has been renamed to "Branch-Based Review Policies." This section now also includes a reference to a separate file containing examples of this automation.

2. Configuration File Updates:

   • In the review_source_branch.cm configuration file:

     • The entries for branch automation have been rearranged so that the name field comes before the prefix field.

   • In the review_target_branch.cm configuration file:

     • A similar rearrangement of fields has been done, with name now preceding prefix.
     • Each branch entry now includes a reviewers field that specifies which team is responsible for reviewing PRs targeting certain branches, such as org/release-team for the Release branch and org/experiment-team for the Experimental branch. Prior, these fields were either not listed or incorrectly aligned with other entries.

[gitstream-cm[bot]]

📜 PR Summary 📜

• Documentation Update:

  • Changed a section title from "Assign Reviewers Based on Target Branch" to "Branch-Based Review Policies" in the README, and updated the corresponding link.

• YAML Configuration Updates:

  • Reordered and added name and reviewers fields before prefix in both review_source_branch.cm and review_target_branch.cm files for consistency and clarity.
  • In review_source_branch.cm:
  • Switched the order of fields within each branch configuration.
  • In review_target_branch.cm:
  • Added reviewers field for each branch configuration to specify organizational teams assigned for code reviews on respective branches.

[gitstream-cm[bot]]

✨ gitStream Review ✨

From the provided diffs, only cm (gitStream Configuration) files are relevant as there are no js file changes. Here is the review of the cm files:

review_source_branch.cm

1. Bug/Consistency:

   • The keys under branches are now structured consistently with both name and prefix fields. This update addresses any inconsistency present in the previous versions regarding the key ordering.

2. Performance:

   • No performance issues identified within this configuration file as it primarily deals with setup logic.

3. Best Practices:

   • The use of a regular expression (prefix) for branch matching is an efficient approach and considered a best practice.
   • Correct use of templating with adequate safety checks ({% for item in branches %}) is positive.

4. Improvement Suggestions:

   • Ensure that the regex patterns are adequately tested to match the intended branches and don't accidentally match unintended ones.
   • Review the logic for setting approvals and the actual add-reviewers@v1 action to ensure they are aligned with organizational policy or changes in the team structure.

review_target_branch.cm

1. Bug/Consistency:

   • The file has been updated to consistently include name, prefix, and reviewers for branches. This provides a cleaner data structure and better maintainability.

2. Performance:

   • Regular expressions are used efficiently; ensure the patterns efficiently match the correct branches without performance drawbacks.

3. Best Practices:

   • The structured approach of including mandatory reviewers in the configuration allows for centralized control and is in line with best practices.

4. Improvement Suggestions:

   • Check that the reviewer assignments (reviewers: org/release-team and reviewers: org/experiment-team) reflect current team membership to keep review processes up to date.
   • Consistent use of naming conventions in automation naming (e.g., review_target_branch_{{ item.name }}) can improve clarity.
   • Consider expanding comments within the YAML for documentation purposes, particularly for complex regexes or specific logic choices, to aid future maintainers.

No security risks are apparent in the changes, but ensure that the data in reviews and reviewers variables sourced from any external input is validated and sanitized.