Repository settings

Some controls in this repository live in its settings on the hosting platform, and the Terraform files in infra/github/ declare some of them. A maintainer applies those files by hand, so a pull request can’t change a live setting, and no workflow can enforce one. This page lists the settings that the release, landing and security pages depend on, with each one’s value and the file or settings page that holds it. Formal models says which branch rules keep develop and main tested, and the GitHub Actions security checklist reviews these settings against the OWASP cheat sheet.

Settings

Setting	Value	Declared or set in
Required checks on main	Check and Changeset from CI, and Scan from gitleaks, on a branch that is up to date with main	infra/github/protection.tf
Reviews on main	Code-owner review, with stale approvals dismissed and no minimum approval count	infra/github/protection.tf
Deletion of develop	Blocked by a ruleset, except for repository admins. Force-push to develop isn’t blocked: the sync’s reset of develop to main force-pushes with GITHUB_TOKEN, and a ruleset can only exempt apps the organization installed, which the built-in GitHub Actions app isn’t	infra/github/rulesets.tf
Force-push to main, and its deletion	Blocked	infra/github/protection.tf
Secret scanning and push protection	On	infra/github/repository.tf
Merge methods	Squash only, for the release PR as for every other PR, as Release schedule says	infra/github/repository.tf
release environment reviewers	The maintainer, betsalel-williamson, from release_reviewer in infra/github/variables.tf. It has to be a user: the repository’s owner is an organization, and an organization’s ID leaves the environment with no reviewer	infra/github/environments.tf
release environment admin bypass	On, so a repository admin can deploy without a reviewer’s approval	infra/github/environments.tf
release environment deployment branches	main and v* tags	Settings → Environments → release
RELEASE_GITHUB_TOKEN	A secret of the release environment	Release token
DEPENDABOT_CHANGESET_TOKEN	A repository secret	Dependabot changeset token
Default GITHUB_TOKEN permissions	Read-only	Settings → Actions → General → Workflow permissions
GitHub Actions can create and approve pull requests	On. When merging main back into develop conflicts, the sync workflow opens a pull request with its own GITHUB_TOKEN	Settings → Actions → General → Workflow permissions
Pages source	GitHub Actions, for the site deploy	Settings → Pages
github-pages environment deployment branches	develop	Settings → Environments → github-pages
Trusted Publisher of each npm package	release.yml in this repository	The package’s npm settings, as Trusted Publishing describes

Terraform

infra/github/ declares the settings whose row names a .tf file, with the integrations/github provider. It also declares settings that no page here depends on, such as the repository’s description and topics. Its imports.tf adopts the existing repository, main protection and release environment. An apply then changes them in place. The provider can’t set the branch and tag policies of an environment on a user account’s repository, and environments.tf leaves them to the settings page.

The live settings can drift from the files between applies. This repository applies them with OpenTofu, and terraform runs the same files with the same subcommands. With admin access to the repository, set GITHUB_TOKEN to an admin token, then compare from the repository root. The plan lists each live setting that differs from the files:

tofu -chdir=infra/github init &&
tofu -chdir=infra/github plan

Apply once the plan shows only the changes you expect:

tofu -chdir=infra/github apply

OpenTofu writes its state to infra/github/terraform.tfstate, and infra/github/.gitignore keeps that file out of commits, along with .terraform/ and plan files.

Code-owner review

.github/CODEOWNERS assigns a code owner to every path, with entries of their own for .github/, packages/, docs/, skills/ and .agents/skills/. CODEOWNERS alone doesn’t block a merge. The code-owner review on main does, as the OWASP cheat sheet recommends for changes from external contributors. Pull requests from forks still run CI under the base repository’s policy, and the code owner that CODEOWNERS names approves each change to an owned path before it merges. The rule’s minimum approval count is 0, because only maintainers can merge.

With admin gh auth, read the live review settings, or repair them without Terraform:

gh api repos/Merlon-Docs/merlon/branches/main/protection \
  --jq '.required_pull_request_reviews | {require_code_owner_reviews}'

gh api -X PATCH repos/Merlon-Docs/merlon/branches/main/protection/required_pull_request_reviews \
  -F require_code_owner_reviews=true \
  -F required_approving_review_count=0

Required checks and scanners

protection.tf doesn’t list Release source among the required checks on main. Formal models says what goes wrong without that rule.

CodeQL and Zizmor run on every pull request that isn’t a draft. CodeQL also runs on each push to main, so code scanning keeps an analysis of the default branch to compare pull requests against. Zizmor uploads nothing, and every change reaches main through a pull request it scanned, so it doesn’t run on a push:

• CodeQL, the Analyze job, analyzes javascript-typescript for the package sources and actions for workflow queries in one run, and uploads SARIF to code scanning. Safe markdown parsing says how a ReDoS finding on a library regex gets fixed.
• Zizmor scans the workflow files for misconfigurations. The job fails on a finding and annotates the pull request.

protection.tf doesn’t list Analyze or Zizmor as a required check. A finding from either one shows on the pull request, and its reviewer weighs it. Landing on develop says when the scanners first see a landing’s changes.

Branch rules on develop

infra/github/ doesn’t declare a rule for develop. Formal models names the two branch rules that develop needs, and the identity of the land workflow that they have to exempt.