尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
不到45天!GitHub为活跃仓库指定所有者,存档8000个不再使用仓库
GitHub为仓库指定可靠所有者GitHub拥有超过14,000个仓库但其中只有不到一半有明确的所有者。在不到45天的时间内GitHub为每个活跃仓库指定了经过验证的所有者将其余仓库存档并使所有权成为后续工作的基础。原有所有权模型的困境GitHub在主要的内部GitHub组织中拥有超14,000个仓库。截至2025年初超11,000个非存档仓库中绝大多数无明确所有者。对于与生产服务相关的仓库历来有可靠的持久所有权但对于无关联服务的仓库却无可靠方法确定所有者。在密钥扫描修复工作中此问题反复出现不知道仓库所有者时轮换密钥风险大、干扰多且无明确方法分配修复工作。多年来GitHub通过内部服务目录跟踪已部署服务的所有权服务条目记录元数据可建立从服务到仓库的映射还记录所属团队、执行发起人及支持信息。但这种关系是多对一的从服务入手可找仓库及其所有者从仓库出发找所有者需反向查找且仅适用于映射到服务目录中服务的仓库留下巨大所有权缺口包括团队仓库、文档仓库等。每次联系“无主”仓库所有者都需手动操作对于重复性安全工作流程带来真正风险在密钥扫描清理工作中寻找合适所有者花费大量时间。设计新所有权模型GitHub需要将仓库所有权作为首要属性考虑过将所有权存储在每个仓库内的专用文件中或维护在一个集中的仓库中最终选择了GitHub自定义属性这种方法提供原生、结构化且可在整个组织范围内查询的方式管理所有权还能根据所有权类型有选择地执行企业和组织政策及规则集。GitHub创建了两个自定义属性“ownership - type”和“ownership - name”。“ownership - type”接受“Service Catalog”“Hubber Handle”“Team”三个值涵盖了GitHub仓库所有权的实际范围“ownership - name”是经过轻度验证的文本字段GitHub应用程序会验证每个值在格式方面有意放宽要求希望让添加所有权轻松无压力并依靠强大的验证捕捉无效条目。首日覆盖情况在要求任何人采取行动之前GitHub建立了一个从服务目录到仓库自定义属性的定期同步机制。每个支持已知服务的仓库都会将其“ownership - type”设置为“Service Catalog”并自动填充“ownership - name”处理了约1,500个由服务支持的仓库剩下团队仓库、文档仓库、一次性项目和个人仓库。推广过程为推广新模型GitHub构建了一个由Kubernetes CronJob支持的GitHub应用程序因执行逻辑需访问服务目录、GitHub API和一些内部系统简单的GitHub Actions工作流不够。仓库所有权执行流程从最初的所有权扫描到创建警告问题再到自动关闭或在30天后进行存档。GitHub将CronJob的首次运行安排在周六早上但问题开始出现在整个组织的仓库中人们在Slack上询问仓库中说要被存档的新问题。经过30天宽限期后将仍未设置所有权的仓库进行存档存档可逆且非破坏性若有人再次需要可取消存档、设置所有权并继续使用。初始宽限期过后将执行周期从30天缩短到一小时新仓库若绕过创建时所有权要求会立即被标记。遇到的问题及解决办法此过程总体顺利但有两起轻微内部事件暴露出有趣的边缘情况。第一起事件因存档未设置所有权的仓库Datadog被配置为在该仓库中创建问题仓库被存档后无法创建问题内部监控服务注意到并向所属团队发送警报问题升级。这暴露出通知方式漏洞通过在所有权问题上提及仓库管理员并将所有具有写入权限的用户作为后备分配解决问题。第二起事件是数据可靠性问题未考虑服务目录可能返回过时或损坏的数据若错误数据导致应用程序认为一批仓库失去服务目录条目会大规模存档拥有有效所有者的仓库。为降低存档合法仓库的风险设置了下限每次运行前应用程序统计即将进行的存档数量和即将创建的问题数量若超过保守阈值将停止操作并触发Datadog监控若无法访问服务目录作业将跳过服务目录验证只检查能独立验证的内容。数据结果最终GitHub有大约3,000个活跃仓库和11,000个存档仓库最初存档约3,000个。从第一次运行到稳定状态整个过程不到45天。现在每个活跃仓库都有经过验证的所有者否则就会被存档。许多新存档的仓库多年未提交代码存档减少了管理范围使活跃仓库清单更符合实际情况。确保所有权持续有效实现100%的覆盖只有在能够保持的情况下才有意义因此GitHub在每个仓库创建工作流程中都强制执行所有权属性包括仓库创建页面、内部工具和自动化流程使这些属性对所有新仓库都是必需的。同时收紧了执行周期失去所有权的仓库会在一小时内被标记出来。每种所有权类型都有其自身的持久性特点服务目录条目遵循服务生命周期服务被弃用时其仓库通常也会被存档团队会被验证是否至少有两名成员团队的存在和成员资格往往相当稳定个人Hubber用户名只有在有人离开公司时才会失效此时个人仓库通常应被存档。对于重要到能超越个人的仓库所有权应该是团队或服务而不是个人。对您的启示您现在可以使用GitHub自定义属性实现类似的所有权模型推荐方法如下定义您的所有权分类确定适合组织的所有者类型在组织级别创建自定义属性设置“ownership - type”属性作为单选框包含允许的值以及“ownership - name”属性作为文本字段如果有服务目录或资产清单进行同步为已跟踪的仓库填充所有权在仓库创建时强制执行所有权使这些属性成为必需为现有仓库构建宽限期工作流程创建带有合理截止日期的问题然后存档无人认领的仓库不要在周六进行第一次强制执行在大规模信任自动化之前构建防护措施假设数据源偶尔会出错通知有时会丢失从一开始就为此进行设计。
RELATED

相关推荐

【读书笔记】《浪花淘尽英雄:亲历全三国史》

【读书笔记】《浪花淘尽英雄:亲历全三国史》

《浪花淘尽英雄:亲历全三国史》内容整理本书作者为北师大历史学教授,以简洁流畅的文笔梳理了三国的完整历史脉络。一、乱世之源:黄巾起义 中国古代政治格局历来由三股力量角逐:皇权、外戚、宦官,士大夫与皇帝共治天下。…

📅 2026/9/11 22:29:17
龙陨纪元服务器:躺平变强机制与RPG深度玩法全解析

龙陨纪元服务器:躺平变强机制与RPG深度玩法全解析

最近在和朋友联机玩《我的世界》时,发现很多服务器要么玩法单一容易腻,要么升级太肝让人望而却步。刚好体验了一款名为"龙陨纪元"的大型原创RPG服务器,它巧妙地将"躺平变强"机制与深度RPG玩法结合,即使不爆肝…

📅 2026/9/1 6:58:30
基于TI SPPDMMulti框架的蓝牙双模多连接开发实战指南

基于TI SPPDMMulti框架的蓝牙双模多连接开发实战指南

1. 项目概述与核心价值在物联网设备开发中,无线连接能力是决定产品体验的关键。我们常常面临一个选择:是使用低功耗但速率和连接数受限的BLE,还是选择功耗稍高但带宽和稳定性更优的经典蓝牙?更复杂的是,很多场景需要设…

📅 2026/9/4 19:47:30
MORE NEWS

更多资讯

📰

为什么大厂都在“降级”技术栈?真相令人深思

“我们是不是该把微服务拆回去了?”“Go写得爽,但GC卡得受不了,要不换Rust试试?”“JAX的MFU低到离谱,直接用C从头写吧。”这些对话,正在国内外大厂的会议室里真实发生。当外界还在追逐“云原生”、“微服务…

📰

SSM鲜花销售系统:Java Web教学与毕设经典实践

简介:本资源是一套面向计算机专业毕业生与JavaWeb初学者的SSM框架实战项目,聚焦鲜花销售业务场景,完整覆盖毕业设计所需的系统开发全流程——从需求分析、数据库设计(MySQL)、SSM三层架构实现(SpringSpring…

📰

钙质土中重力锚水平承载力有限元分析与优化

1. 项目概述:钙质土中重力串锚水平承载力有限元分析重力锚在海洋工程、桥梁建设等领域应用广泛,其水平承载力特性直接关系到结构安全性。钙质土作为一种特殊地质材料,具有高孔隙比、易破碎等特点,传统理论公式往往难以准确预测其力…

📰

基于SpringBoot+Vue的学校热点新闻推送系统:RBAC权限设计与实践

简介:一份基于 Vue、Spring Boot 与 MySQL 的学校热点新闻推送系统毕业设计资源,面向需要完成课程设计或毕业设计的计算机专业学生,也适合想学习前后端分离项目结构、RBAC 权限模型及 Vue 与 Spring Boot 整合的中级开发者。系统以热点新闻管…

📰

用Python拆解看图猜成语小程序:题库生成与前端实现精讲

简介:一个基于Python与微信小程序搭建的看图猜成语游戏项目,面向Python初学者和小程序开发者,完整还原了从后端接口到前端交互的开发链路。资源共40个文件,压缩包仅559KB,其中6个py脚本实现Flask后端逻辑,4…

📰

基于LangChain+LLM大模型+机器学习的恶意域名(流量)智能检测系统

无需借由LLM就能生成基础检测报告, 参照实际字符特征以及训练数据的统计来解释风险线索, AI复核给出进度与阶段有文字展现出的提示, 训练输出日志和任务的状态, 这些反映的是执行进程, 并非是在展示大模型内部的思维链。3.6 六维可视化安全工作台用于工作台的使用, 其作用是展示…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬