Choose who can approve

Choose which GitHub teams and people may approve releases for each area of your code, per environment. It takes about 5 minutes, and you need to be a company admin in Zof and an admin of your GitHub organization.

An area is an owner from your System map, such as owner:team-payments, with the services and repositories it owns. When a rule needs an approval, Zof asks for one from the owners of the services the change touches. A review counts when the reviewer is listed for that area, or is an active member of a listed team, can write to the repository, didn't write the change, and approves the latest commit after checks pass.

Before you start

• GitHub is connected to your company. Otherwise the page asks you to connect GitHub first.
• Your System map names owners for your services. Areas come only from it.
• You're a company admin in Zof and an admin of the GitHub organization. Saving needs both. A company admin who isn't a GitHub org admin sees the list read-only, with a note that only a GitHub org admin can change it. See Who can do what.

Open Release approvers

1. In the sidebar, open Admin.
2. In Admin, open Roles and go to its Release approvers section (Release approvers).

Each area is a card with a row per rule: Production and Staging when the area has its own rule for them, then Every other environment. An area with only the default rule shows Every environment. Each row shows the approvers, how many approvals it needs, when an approval expires, and who can approve now.

When the environment filter in the header names an environment, each area shows only the rule that applies there, and "Show all environments" brings back every rule. Edit always shows every rule.

A red banner lists System map areas with no approvers yet. Changes to them that need approval are blocked. The Needs attention filter shows those areas, plus areas where too few people can approve.

Add an area

1. Click Add area.
2. Search by area, service or repository, and pick the area. You can also move through the list with the arrow keys.
3. Click the button that names the area, such as "Add Payments", or press Enter. When your System map suggests a GitHub team, shown next to the area as a handle such as @payments, it is added for you.
4. Choose approvers as below, then click Save.

Areas that already have approvers aren't listed as choices; "Show added" lists them. Hover an area to see its owner ID.

When some services have no owner, one line says how many, such as "8 services have no owner", with a link to Set owners in System map. Open it to see each service with Set owner. Give them an owner in your System map first.

For an owner with no service in your System map, such as owner:@login, open Advanced: owner ID and type the ID.

Choose approvers

1. On the area, click Edit.
2. In a rule, click Add team or Add person, search, and pick.
3. Set Approvals needed. It can't go below what your release policy asks for; when a policy rule asks for more, the higher number wins.
4. Set Approval expires. A new commit always needs a new approval.
5. Check Who can approve with these settings.
6. Click Save.

Add person shows, for each person, whether they can write to the area's repositories. A review from someone who can't write doesn't count.

To give Production or Staging its own approvers, click Production or Staging under "Need different approvers somewhere?". A new Production rule asks for at least 2 approvals that expire after 24 hours. Use default removes the rule, so that environment uses Every other environment again.

If too few people can approve a rule, a red warning says so before you save. You can still save, but changes that need approval there stay blocked.

Saving makes a new version, and Zof checks every open pull request again with it. History lists the versions.

Areas not in the System map

An area saved earlier that no service in your System map names now shows Not in System map and "Not used": no change asks those approvers. Click Remove to delete it, or set the owner on a service in your System map.

When the environment is unknown

If Zof can't tell which environment a change goes to, it doesn't fall back to Every other environment. The change needs the approvals of every rule of its area. See target_environment_unknown.

Members read permission

Approvals through a team need the Members: read permission on the Zof GitHub App. Zof uses it to check that a reviewer is an active member of a listed team. On GitHub, the Zof GitHub App appears under the name it was registered with, which is Zof AI on Zof's hosted service.

If the page shows Team approvals can't be checked, Zof can't check team membership. Approvals through a team don't count until an organization owner accepts the Members: read permission for the app.

1. An owner of the GitHub organization opens "Organization settings" on GitHub.
2. Under the installed GitHub Apps, they open the Zof GitHub App (Zof AI on Zof's hosted service).
3. They review and accept the updated permissions.

While Zof can't check a reviewer's teams, the check says "A reviewer's teams are unresolved; retrying." and Zof retries about once a minute. A "Request changes" review it can't check still blocks the change, because Zof can't tell that it isn't a real veto.

If the page says "Couldn't confirm the Members: read permission with GitHub.", GitHub didn't answer. Reload the page later.

Check that it worked

1. On Release approvers, the area shows the teams and people you added, with who can approve now.
2. History lists a new version with your GitHub login.
3. On a pull request waiting for approval, a listed approver approves on GitHub. Its Zof / Control check stops asking for that approval.