Skip to content

Spoke Pull Request Review

Reviewer runbook for pull requests that create or change a spoke file. Use it with the general checks of Pull request review. The fields and their meaning are in the Spoke JSON reference.

1. Check the state of the pull request

Check Action when it fails
The pull request is not a draft Comment on the ticket: the requester must finish it first.
The required checks passed Queue the pipeline again if the result expired. If it failed, comment on the ticket and wait for a fix.
All comments are resolved Comment on the ticket and wait.
A ticket is linked Link it, or make the check optional if the platform does not need it.

Required checks depend on the platform

Whether the validation pipeline is a required check on the spoke repository depends on the platform. Where there is none, run the config tests yourself (Run the tests locally).

If your platform runs a validation pipeline on spoke files, it checks JSON validity, the schema, the private link subnet and the file name against the environment (Validate spoke files). It does not replace the checks below.

Send the pull request back as described in Pull request review.

2. Review each file

Do this for every file in the pull request. Open the Files view.

2.1 File name (new spokes, and when a name changed)

The file name follows the convention of your platform, ends in .json, and is unique across all sub-folders of spokes/. Many platforms use a pattern like canvas_<workload>_<environment>.json. Some also encode production and non-production in the name (canvas_prod_..., canvas_nonprod_...). The file must be in a sub-folder.

2.2 Subscription

azureSubscriptionId must be filled in for a new spoke, and be an existing subscription. If it is empty, the subscription has to be created first, by the process of your organisation (New spoke). Put the ID into the file and commit it to the branch.

2.3 Existing spokes

workloadShortName and environment of an existing spoke are unchanged. A change creates a new state key and a second spoke (Change spoke).

2.4 Storage account and Key Vault (new spoke, or when the configuration changed)

Check If it is not as expected
Storage account: EnablePublicAccess is false and CreatePrivateEndpoint is true Ask the requester whether that is intended.
Storage account: infrastructure_encryption_enabled is true Ask whether that is intended.
Storage account: allow_nested_items_to_be_public is false Ask whether that is intended.
Key Vault: enablepublicaccess is false and createprivateendpoint is true Ask whether that is intended.

2.5 Address spaces (new spoke, or when addresses changed)

  • There is exactly one resourceconfiguration.network entry for each region in targetRegions.primary and targetRegions.additional.
  • Every subnet prefix (subnets[*].addressPrefix) lies inside the address space of its network (addressPrefix).
  • The subnets do not overlap with each other. Use a subnet calculator to be sure.
  • The range does not overlap with any other range of the IP plan, and it is recorded there. The code does not check overlaps.

2.6 Subnets (when updated)

  • Each network has a subnet with isprivatelinksubnet set to true. One is the convention.
  • Delegations are names from the list of the schema. Service endpoints are as requested.

2.7 Network security groups

Every network security group that a subnet names in linkednetworksecuritygroupname must also exist in the networksecuritygroups list of the same network. If not, ask the requester to add it. An existing NSG rule keeps its priority (Change spoke).

2.8 Identity and tags

  • The groups in adInfo.ProductTeamGroupNames exist in Entra ID.
  • PIMGroupConfig has a valid mode per role (nopim, self-approve, approval).
  • The tags include owner, department, workload, pii, costcentre and environment.
  • The management group (managementGroupId) fits the usage type: production data, personal data and exposure to the internet.

3. Final review

  • Set auto-complete if it is not set, with resolve work item after merging off and delete source branch on.
  • All checks in order: approve the pull request, and deploy (Spoke deployment).
  • Something is wrong: give clear feedback and ask for changes.

2.9 Extensions (when changed)

  • An extension is only enabled when the shared service exists in shared_services and the workload needs it (Spoke extensions).
  • The plan after the change shows the role assignments and groups of the extension, and no deletes.