beaus-tolling-roadside

GitHub Governance

Repository Standards

The roadside repository should operate like a production infrastructure and platform repository.

Required Baseline

• main and staging branches
• pull-request-only change flow
• CODEOWNERS
• required CI and security checks
• release notes automation
• dependency update automation
• conventional commit discipline

Files Included in This Repository

• .github/workflows/ci.yml
• .github/workflows/dependency-review.yml
• .github/workflows/codeql.yml
• .github/workflows/secret-scan.yml
• .github/workflows/release-drafter.yml
• .github/workflows/deploy-staging.yml
• .github/workflows/deploy-production.yml
• .github/workflows/review-reminder.yml
• .github/CODEOWNERS
• .github/pull_request_template.md
• .gitmessage.txt
• .githooks/commit-msg
• tools/github/configure-repository.sh
• tools/github/bootstrap-teams.sh
• tools/github/configure-environments.sh
• tools/github/seed-placeholder-config.sh
• tools/github/apply-branch-protection.sh

Bootstrap Order

For a new repository, run:

1. bash tools/github/configure-repository.sh <owner>/<repo>
2. bash tools/github/bootstrap-teams.sh <owner> <owner>/<repo> if the owner is an organization
3. bash tools/github/configure-environments.sh <owner>/<repo>
4. bash tools/github/seed-placeholder-config.sh <owner>/<repo>
5. bash tools/github/apply-branch-protection.sh <owner>/<repo>

For personal public repositories used to publish GitHub Pages:

• use individual-user CODEOWNERS, not organization teams
• keep the repo public so Pages can be served without additional platform cost
• publish Pages from main/docs

Plan Constraints

This repository is designed to stay on the lowest-cost GitHub organization footprint that still supports private code. That choice comes with trade-offs:

• private repositories on GitHub Free do not expose the full branch protection API
• required deployment reviewers for GitHub Environments are not available
• environment deployment branch policies are not available

For a private tolling platform repository, the practical recommendation is:

1. keep the repository private
2. upgrade the organization to GitHub Team before relying on enforced release approvals
3. use the bootstrap scripts in this repository as the source of truth so the missing controls can be applied immediately after the upgrade