Skip to main content
Checks that all code changes are reviewed by at least one peer before merging in GitLab.

​
About

When you connect GitLab to DSALTA, the platform reads your repository configuration using read-only API access. DSALTA activates this check when a repository does not enforce the required controls.

​
Why This Matters

Code merged without an independent review bypasses a critical quality and security gate, letting bugs, vulnerabilities, or malicious changes reach production. Requiring peer review and passing checks before merge is required by SOC 2 and ISO 27001 secure-development controls.

​
How to Fix

Before you begin
  • Ensure you have admin access to the GitLab repository or organization.
Enforce branch protection and peer review
  1. Open your GitLab repository settings and go to Branch protection rules (or the equivalent).
  2. Add a rule for your default branch (for example main).
  3. Enable Require a pull request before merging with at least 1 required reviewer (so the author cannot self-approve).
  4. Enable Require status checks to pass before merging and select your CI checks.
  5. Enable Include administrators so the rule applies to everyone, and disable force pushes and deletions.
Once branch protection and peer review are enforced, DSALTA retrieves the change on the next sync and sets the check status to Passing.

​
Frequently Asked Questions

This check runs automatically every 24 hours while the GitLab integration is connected. You can also trigger a manual sync from Integrations in the sidebar.
A failing check appears in your Data Library → Tests dashboard. Work through the steps above; once the underlying configuration is fixed, the status updates automatically on the next sync.
Yes. If it does not apply to your environment, mark it as Not Applicable with a justification. The exclusion is documented for auditors.
No. DSALTA uses read-only API access and never modifies, creates, or deletes resources. All remediation is performed by your team directly in GitLab.