github - 允许更广泛地发现私有(private) GitHub 存储库的好方法是什么？

Question

如果您在一个组织中，可能会有私有(private)的 GitHub 存储库(即您无权访问它们)，但了解它们的存在会很有用，然后您可以在适当的地方安排访问。

换句话说，我们正在尝试以一种可以导致访问的方式实现可发现性。这可以通过共享自述文件来完成(注意人们需要有一些纪律才能编写合理的自述文件)。

这篇博文 Solving the innersource discoverability problem看起来像是一个潜在的解决方案，但可能需要用户有权查看门户中的所有 repo 协议(protocol)？我希望用户能够查看所有存储库的自述文件 - 如果他们没有访问权限，可以联系自述文件中列出的任何人。

我看到了另一个从私有(private)仓库公开文件的选项(使用 gitexporter 创建一个只有自述文件的公共(public)仓库，example here。这使它公开，而不是我的第一选择，并且需要每个仓库都做一些工作，远非理想。虽然它没有提供整洁的门户，但它应该允许 GitHub 搜索功能按主题或关键字找到它？

提出了一个相关的、也许更简单的选项 here ，学生将私有(private)仓库中的自述文件分享为公共(public) GitHub 页面。同样，需要从每个 repo 做一些工作，没有整洁的门户，但可以通过 GitHub 搜索找到吗？虽然公共(public) Github 页面可以设为私有(private)，但只有具有 repo 访问权限的人才能看到吗？

因此，如果我总结基本要求:

• 所有组织存储库(公共(public)、私有(private)或团队)都有一个自述文件，组织中的某个人可以通过搜索访问该自述文件(最好不需要每个人修改他们的存储库)。

其他不错的功能:

• 所有自述文件都可以在带有搜索功能的门户中查看
• 能够将 super 私有(private)(只有合作者可以看到自述文件 - 在自述文件中标记？)、组织私有(private)(只有组织中的人 - 默认)和公共(public)(在自述文件中标记？)。
• 易于实现!

建议？

Answer 1

我想你已经为它提供了合适的解决方案here已经在你的问题中。或者，您可以使用 API(GET repos、GET README of a repo)获取每个存储库 README 并将其保存到基于 cron 调度程序的数据库/JSON，并基于该数据创建 Web 界面。

但是，我将详细说明一些需要改进的地方。我看到的问题是搜索的性质。我们并不总是在寻找关键字，有时我们会尝试为我们的问题寻找潜在的模糊匹配，尤其是在拥有超过几千个存储库的大型组织的情况下。在这些情况下，搜索引擎实现将提供更好的结果。在我看来，我们应该收集 README 和 FAQs 并将它们放入 Elastic search，公开搜索 API 以供查询。 README 和 FAQ 的集合应该是 CI/CD 管道的一部分，在将新版本推送到 artifactory 的同时，它还必须发布元数据。