Skip to main content
When several workspaces share one Git repository, you can require that changes to a specific workspace are approved by a named group of people, while changes to the other workspaces are unaffected.

​
How it works

Each workspace is a separate top-level folder in the repository — the sales workspace lives in /sales/ (see repository structure). When a user clicks Publish changes in Honeydew Studio, a pull request is opened into the repository’s default branch. A path-based approval rule in your Git provider requires approval from a named group on any pull request that changes files in the workspace folder. Because the rule is tied to a folder path, it applies only to pull requests that touch that workspace. All major Git providers support such rules — see Other Git providers. The section below covers GitHub.
This controls who approves changes before they reach prod. It does not control who can edit the workspace in Honeydew Studio — for that, see workspace level access control.

​
Require approval for a workspace on GitHub

On GitHub, the approval requirement is a Required reviewers rule in a branch ruleset. Adding rulesets requires admin permissions on the repository, and the approvers must be in a GitHub team — the rule accepts teams, not individual users. The example below protects a workspace whose folder is sales, using a team called sales-approvers.
1

Create a team for the approvers

Create a team with the people who should approve changes, and give it the Write role on the repository.
The team must be visible and have Write access to the repository. GitHub ignores secret teams, and teams without write access — even if every member already has write access individually.
2

Create the ruleset

In the repository’s Settings > Rules > Rulesets, create a branch ruleset that is Active, targets the default branch, and has:
  • Require a pull request before merging, with Required approvals set to 0
  • A Required reviewers entry with the sales-approvers team, the number of approvals to require, and the file pattern sales/**
  • An empty Bypass list — if the Honeydew.ai application can bypass the ruleset, it merges pull requests automatically and the approval requirement never applies (see GitHub setup)
Set Required approvals to 0. It applies to every pull request in the repository, so any value above 0 would also require approvals for your other workspaces. The Required reviewers entry is what requires approval for the protected folder.
File patterns use .gitignore syntax. A deeper path, such as sales/entities/**, protects part of a workspace instead of all of it. To protect more than one workspace, add a reviewer entry for each.
Keep this ruleset separate from the one that requires the validation status check. A bypass applies to a whole ruleset — with separate rulesets, the Honeydew application can keep bypassing the validation check for unprotected workspaces while being unable to bypass the approval requirement.
Require a pull request before merging applies to the whole default branch: direct pushes stop working for every workspace, including direct edits to metadata files. Pull requests for the other workspaces still merge without approval.
To name individual users as approvers, or on a user-owned repository that has no teams, use a CODEOWNERS file with the Require review from Code Owners rule instead. The folder patterns then live in the CODEOWNERS file rather than in a Required reviewers entry; the Required approvals setting, the bypass list, and the repository-wide effects are the same.

​
Troubleshooting

Check, in order:
  • The folder pattern matches the workspace folder name exactly, including capitalization. A non-matching pattern requests no reviewers and reports no error
  • The Enforcement status of the ruleset is Active
  • The ruleset targets the default branch
  • Neither the Honeydew application nor the person merging is in the Bypass list
Usually the team cannot be resolved. Common causes:
  • The team is secret rather than visible
  • The team does not have Write access to the repository
  • The team belongs to a different organization than the one that owns the repository
  • The folder pattern does not match any file that the pull request changes
Required approvals is set above 0. That setting applies to every pull request in the repository, independently of the folder pattern. Set it back to 0.Also check that no folder pattern matches all files, such as **.
The approval rules were added to the same ruleset that requires the validation status check, and removing the Honeydew application from that ruleset’s bypass list also stopped it bypassing the check. Move the approval rules into a separate ruleset, and restore the bypass on the validation ruleset.
This is expected: Require a pull request before merging applies to the whole default branch. Open a pull request instead.

​
Other Git providers

All major providers can restrict approval to specific people by path, but the feature has a different name in each, and Bitbucket Cloud does not enforce it:
On Bitbucket Cloud, code owners cannot enforce approval on their own. Use a merge check that requires a minimum number of approvals, keeping in mind that it applies to all pull requests in the repository, not only to one workspace.

​
Limitations

  • Approval is required for every change to the protected folder, regardless of who published it
  • Honeydew opens pull requests through its Git application, rather than as the user who published the change. To enforce separation of duties, keep the people who publish changes out of the approvers team, and require more than one approval for sensitive workspaces