How GitHub Established Durable Repository Ownership
GitHub developed a permanent ownership system for all repositories.
1GitHub's Repository Ownership Problem
GitHub had over 14,000 repositories, many of which lacked a clear owner. This ambiguity, especially for repositories not tied to production services, caused issues in security and workflow efficiency.
2The Old Ownership Model
GitHub tracked ownership for production services through its Service Catalog. However, this model did not apply to many repositories, leading to frequent ownership ambiguities.
3The Secret Scanning Issue
During secret scanning cleanup, finding repository owners took too much time. This uncertainty risked security workflows and slowed down processes.
4The New Ownership Model
GitHub decided to make repository ownership a first-class property. Using custom properties, ownership type and owner name were defined for each repository, facilitating enterprise policy enforcement.
5Ownership Types
The new model defined three ownership types: Service Catalog, Hubber Handle (GitHub employee), and Team. These types covered all repositories at GitHub.
6Automatic Synchronization
An automatic sync was established between the Service Catalog and repository custom properties. This automated ownership determination for service-backed repositories, reducing workload.
7Implementation Process
Ownership enforcement was initiated using GitHub App and Kubernetes CronJob. Repositories without ownership were archived after a 30-day grace period, offering a reversible and non-destructive solution.
8Initial Implementation Experience
The first implementation caused issues as many repositories lacked ownership. However, this process made GitHub employees more aware of ownership responsibilities.
9Outcome and Importance
GitHub's new ownership model improved repository management, enhancing security workflows and corporate efficiency. It also helped prevent similar issues in the future.
Original article: The GitHub Blog — GitHub'da Depo Sahipliği Nasıl Düzenlendi?