Skip to content

Repository settings

The Repository page collects every repository-scoped scenario input in one place. Each section is a structured editor over a file in the config root, so everything you change here stays diffable, scriptable, and editable outside the app. Editors that sit over a single file have a raw-YAML toggle in their header.

In a multi-repo workspace, the switcher at the top of the sidebar picks which repository you are editing.

Sets the repository’s owner, which together with the project folder name forms its owner/repo identity. Renaming the owner updates instances.yml and propagates across the app.

Below the owner field, the organization’s rulesets are edited in place. They live at .overwire/orgs/<owner>/rulesets.json under the workspace config root in the platform’s native export format, and cascade onto every member repository during merge prediction. Each rule carries repository patterns (which repositories it targets), ref patterns, required status checks, and pull request requirements; rule types Overwire does not model are preserved untouched on save. Saving creates the orgs/<owner>/ directory if it does not exist yet.

The organization section with the owner field and an editable organization ruleset

Edits variables.yml as a key-value table, resolved in workflows as ${{ vars.NAME }}.

Edits declarations in secrets.yml. The editor shows names and whether a value is present — values themselves never reach the UI. If literal values would be committed to git, the editor warns and offers to add the ignore rule.

Manages deployment environments under environments/<name>/ for jobs that use environment:. Create or delete environments, then configure each one:

  • Protection rules — required reviewers, a wait timer in minutes, and a local auto-approve toggle. These are the same rules the approval dialog enforces when a run reaches a protected environment.
  • Environment variables — overrides of repository variables for jobs targeting the environment.
  • Environment secrets — environment-scoped secrets, shown as names with a value-present indicator, exactly like repository secrets.

The environments section with protection rules, variables, and secrets for a production environment

Deleting an environment removes its directory and all three config files.

Edits custom-properties.yml — organization-defined repository metadata (team, tier, classification) that surfaces in event payloads as repository.custom_properties.

Edits rulesets.json in the platform’s native export format. Organization rules appear above repository rules with a source badge; they are read-only in this merged view and edited in the Organization section.

Edits statuses.yml — pre-staged external commit statuses and check runs, the way a third-party CI or scanner would have reported them upstream. Two tables:

  • Commit statuses — context, state, and a target (ref, sha, or pr).
  • Check runs — name, status, and conclusion. Completed checks require a conclusion; anything still in progress counts as pending for required-check evaluation.

The statuses section with pre-staged commit statuses and check runs per pull request

Entries whose names match required status checks in your rulesets feed merge prediction on the pull requests page and workflow_run scenarios. Timestamps and details URLs are preserved on save and editable through the raw-YAML view.

overwire.io

Overwire is not affiliated with, endorsed by, or sponsored by GitHub, Inc., Microsoft Corporation, or Docker, Inc. GitHub and GitHub Actions are trademarks of GitHub, Inc.