Policies

Policies let you enforce merge conditions on pull requests with configurable strictness. From advisory-only observation to hard merge blocking, policies give you granular control over what gets merged into your codebase. Combined with circuit breakers and fail-open behavior, policies are designed to protect without disrupting your workflow.

How It Works

When a PR is opened or updated, TinyOps evaluates all active policies against it. Each policy checks one or more conditions and posts a commit status to GitHub. Depending on the enforcement level, this status either observes, warns, or blocks the merge.

Enforcement Levels

Level	Commit Status	Effect
`advisory`	Success	Observe only. Evaluates and logs but never blocks.
`warn`	Success	Posts a PR comment warning but does not block merge.
`block`	Failure	Posts a failure status that blocks merge via branch protection.

All commit statuses use the context format TinyOps/{policy.slug}, so they appear clearly in your PR checks list.

Circuit Breaker

To prevent a flapping policy from blocking all merges, TinyOps includes a built-in circuit breaker:

Trip condition: 80% or higher failure rate across 5 or more evaluations within 1 hour
Cooldown: 30 minutes after tripping
Behavior: While tripped, the policy posts success status regardless of evaluation result

Fail-Open Design

If a policy encounters an error during evaluation (API timeout, provider unavailable, etc.), it posts a success commit status. Your team is never blocked by TinyOps infrastructure issues.

Built-in Templates

TinyOps ships with 6 policy templates you can activate and customize:

Template	Description	Default Threshold
`require-tests`	Requires test file changes in the PR	N/A
`max-pr-size`	Blocks PRs exceeding a line count	500 lines
`require-review`	Requires at least one approving review	N/A
`require-labels`	Requires at least one label on the PR	N/A
`no-oversized-unlabeled`	PRs with 300 or more lines need an “architecture” label	300 lines
`cost-budget-check`	Vercel MTD spend must be $500 or less	$500

Configuration

policy-example.yaml


name: max-pr-size
slug: max-pr-size
enforcement: block
conditions:
  - operator: AND
    rules:
      - field: pr.changed_lines
        operator: lte
        value: 500

Condition Logic

Conditions support AND/OR grouping with the same operators available in rules:

compound-conditions.yaml


name: no-oversized-unlabeled
slug: no-oversized-unlabeled
enforcement: warn
conditions:
  - operator: OR
    rules:
      - field: pr.changed_lines
        operator: lt
        value: 300
      - field: pr.labels
        operator: contains
        value: "architecture"

Conditions use the same operator set as rules (eq, neq, gt, gte, lt, lte, contains, not_contains). See the rule reference for full documentation.

Advisory Promotion

Policies set to advisory can be promoted to warn after they have proven stable:

Minimum age: 7 days since creation
Minimum evaluations: 10 successful evaluations

Once both criteria are met, the promotion option appears in the policy detail page. This lets you build confidence in a policy before it starts warning your team.

PR Health Pack - health scoring that policies can reference
Simulation Mode - shadow-test rules before attaching them to policies
Approvals - require human sign-off for policy changes
Audit Log - track policy creation, updates, and promotions