Gitea: Gitea 托管 Gitea

好主意！

2月1.2，4月1.3，6月1.4，8月1.5？ 应该有足够的时间来实现所有这些😄

如果您还没有看到它，那么只有在准备好后才能支持您的自托管方法的精彩而有见地的评论： https :

@lunny现在我想起来了（感谢@zellyn的链接😂）为什么我们需要 oauth-provider、_complete_ webhook 支持、api-documentation 和 _complete_ API 来进行自托管？

OAuth _Consumer_ 是必需的（它已合并 AFAIK），因此人们可以使用 github auth 登录。
Drone 只使用 push hooks，那么我们为什么需要另一个呢？

至于 API，不确定为什么自托管完全需要 TBH :)

我同意修剪该列表。 早期的自托管很可能会帮助我们更好地设置优先级:)

@bkcsoft也许我们可以设置一个托管站点并尝试一下。

@bkcsoft我更新了问题，你是这个意思吗？

-> OAuth 提供者 (#27) 未关闭

@ekozan没有关闭，而是从“我们需要的东西”列表中

添加了“存储库大小限制”，因为我们在服务器上没有无限的存储空间......

我的限制建议：

• 0 个组织
• 3 回购
• 1GB/回购

@bkcsoft你的意思是它会成为任何人的公共服务吗？

也许，也许不是，但_如果_它成为一项公共服务，我们不能无限制地拥有它；）

我认为 dogfooding 非常重要，以至于 repo 大小限制可能不需要成为自托管 gitea 的关键路径。 在迁移到 gitea 后的最初几天，我遇到了几个功能遗漏，这让我认为自托管将有助于集中精力完成这些事情。 Gitea 已经是一个很棒的、高度可用的、高性能的工具——你自己不使用它真是太可惜了。 ;-)

与其依赖硬大小限制，不如考虑如何管理自托管服务器、谁来监管不良行为以及他们需要什么工具，这可能会有所帮助。 例如，gitea 项目的贡献者分支应该在 gitea 自己的服务器上得到支持。 这暴露了用户分叉 gitea，然后将warez 推送到他们的分叉的风险。 大小限制可能有助于防止推送大型二进制文件，但可能无助于密码或信用卡号列表。 在这种情况下可能会有所帮助的工具是通过差异行数或滚动哈希来检测外来文件。

使用 diff-size 工具的一个很好的副作用是，代码可以作为一个选项在推送期间运行，以标记应该被分解成更小的合法提交。 （有关如何执行此操作的相关讨论：https://github.com/go-gitea/gitea/issues/3658#issuecomment-372263759。）

我敢打赌，面向公众的服务器还有很多其他微妙的问题需要解决。 使用单独的“公共托管”主问题或里程碑来跟踪这些事情可能是有意义的。

说到里程碑，这个问题是否应该添加到 1.5.0 中？

@stevegt不，因为我认为并非所有 PR 都会在 1.5.0 中合并/解决。

我从问题中删除了Repository Size Limits (#3658) ，因为它不会影响 Gitea 托管的 gitea。

我从问题中删除了存储库大小限制 (#3658)，因为它不会影响 Gitea 托管的 gitea。

伟大的！ 我很肯定 Gitea 越早托管自己，整个项目就会越快从现实生活中受益，并获得信任和信心 :)

@lafriks在另一个线程中提到：

自托管可能需要额外的资金/赞助来支付额外的虚拟机

@lunny在上面问：

@bkcsoft你的意思是它会成为任何人的公共服务吗？

将这些想法结合到“如何建立一个在线 Gitea 服务，人们为（比如）私人回购付费？”是否可行。

如果做得好，那应该会产生资金来支付自己的费用+公共回购。

作为一个概念，它似乎是相当受欢迎的地方。 ：微笑：

及时添加到@justinclift想法； 微软接管 GitHub 的最新消息可能是正确的时机。

@lafriks在另一个线程中提到：

自托管可能需要额外的资金/赞助来支付额外的虚拟机

我相信社区将提供资金或组织的赞助，以使 gitea 托管本身成为可能。 由于 Gitea 是资源友好型的（是的，GitLab，我在看着你）这没什么大不了的。

@mxmehl自上个月开放集体开放以来，到目前为止已有 5 人做出了贡献： https ://opencollective.com/gitea

@justinclift，因为

@mxmehl自上个月开放集体开放以来，到目前为止已有 5 人做出了贡献： https ://opencollective.com/gitea

@techknowlogick不知道这个页面。 现在是 6 ;)

@lafriks好吧......周围有社区项目 - 软件和非软件事物 - 似乎可以很好地管理自己，包括财务问题、他们支付的东西、员工（在需要的地方）等等。

话虽如此，它确实需要一定程度的意愿才能实现+保持下去。 担任任何所需角色的人也需要成为优秀的保管人（值得信赖、可靠、机智）。

如果没有兴趣，那么它无论如何都不会去任何地方。 如果无法就合适的“保管人”类型达成一致，则同上。

从上面提到的Open Collective链接中，看起来一些初始种子已经到位。 它表明周围有人被认为可以作为保管人。 ：微笑：

@justinclift我并不是说这是不可能的，但不是在当前阶段，但将来可能会发生。 目前，至少我会更好地专注于开发新的 Gitea 功能和改进文档 :) 所以非常感谢任何帮助以更快地实现这一目标。

嘿嘿嘿

完全不用担心@lafriks。 ：微笑：

第一个目标是 Gitea 托管 Gitea，因为 github 与 Microsoft 结婚。 :)

我认为只有 #2519 和 #3748 需要在我们关闭此问题之前进行审查和合并。

@bkcsoft

添加了“存储库大小限制”，因为我们在服务器上没有无限的存储空间......

我的限制建议：

• 0 个组织
• 3 回购
• 1GB/回购

我认为，通过 repos 数量限制，我们可以添加只允许为不属于 Gitea 团队的所有用户设置 fork 现有存储库：

• 0 个组织
• 3个回购（只允许分叉）
• 1GB/回购

我认为不需要限制分叉数量，无论如何它都会受到 gitea org 存储库数量的限制，所以应该没问题。
至于回购规模，是的，可能应该有一些限制

我们应该限制创建 orgs，创建 repos，所以 repo 大小限制对于 Gitea 托管的 Gitea 来说不是必要的问题。

我们可能会考虑将 #3134 和 #4302（PR 和问题反向链接）添加到自托管的 prereq 列表中——也许我是独一无二的，但是一旦我们添加了超过一些用户和问题。 我们已经能够通过问题搜索解决一些问题，但如果没有全局问题搜索（#2434/#3841），这会受到限制。

@stevegt虽然反向链接会很好，但我没有看到它们阻止迁移到自托管:)

@bkcsoft 很公平——只是想我会提到它，以防它触发任何实现。 在我们本地的案例中，我们一直在养成在问题评论中手动添加反向链接作为解决方法的习惯。

我最近听说了https://teahub.io的努力

@jlelse 不，Gitea将建立一个独立的服务器（即 self.gitea.io）来托管 gitea 并镜像到 github、gitlab 或 teahub 等。

@lunny因为我们目前只在 GitHub 的 PR 上使用评论，所以我们真的需要对提交进行评论吗？

@JonasFranzDEV我的意思是对 PR 提交的评论，我认为这是必要的。

我在这里发表评论是因为 #4108 已关闭。 当 Gitea Patreon（或类似 Patreon 的替代品）出现时，我需要知道它。 我会做出贡献的。 我希望看到这个项目自托管并进一步发展。 一旦我移动了我所有的存储库，我将不再在 Github 上花钱，我将每月将其提交给 Patreon。

@ryanburnette https://opencollective.com/gitea

@lunny看起来主题开始中的“审批系统”可以被划掉。 （分别关闭和合并的问题）？

@mjmlvp我认为你是对的。 我删除了#996 #2519，因为它不应该成为这个问题的障碍。 我们将建立一个服务器来托管我们的开发。

有这方面的消息吗？

是的，我们仍然需要添加批准限制，然后我们可以迁移到自托管代码

很高兴将未解决的问题添加到列表中。 目前看起来所有链接的问题和 PR 都已关闭和合并。

@skddc完成。

作为记录

打开gitea服务器

• https://try.gitea.io/
• https://teahub.io/
• https://dev.sum7.eu/

不相信任何人。 定期备份

@giteauser我看不出这有什么关系

@giteauser ，这是关于自托管 gitea 开发，因此 gitea 开发不必再在 github 上进行。 我仍然看不出这是如何相关的。

哦，我把这些贴错了，对不起。

因此，现在应该实现所有需要的功能。 我们可以发布一个新版本并迁移出去吗？

对，我们将设置一个 gitea 实例来托管 gitea 的开发。

我认为修复备份转储问题并添加适当的恢复功能也是管理自托管 gitea 基础架构的重要部分

如果您在 Kubernetes 上部署 Gitea，我可以推荐使用Ark进行备份和恢复。

一般来说，备份似乎不应该成为自托管 Gitea 开发的阻碍话题，因为每个人通常有不同的备份策略/程序，这取决于他们选择的平台、部署方法、现有工具等。它对于该实例的生产准备情况，应该只是一个阻塞问题。

@max-wittig gitea 自托管网站将在一些公共云提供商上运行。 他们将提供 RDS 服务和数据库备份工具以及一些磁盘备份功能，以便备份转储命令不是依赖问题。 dump 命令用于单节点 gitea 服务。 当然，我们应该解决这些问题。

@skddc这是一个有趣的工具，我们可以考虑。

我真的希望 1.8.0 版本将成为 gitea 成为自托管的版本。 我个人很想将它用于我自己的项目，但我只是将 gitea 用作镜像，原因很简单，如果开发人员——你们——甚至不将它用于 gitea 开发，我就不够信任它。 另外，我想提议在我的工作环境中使用 gitea，但我什至无法提议，因为当我说：“哦，顺便说一句，它看起来很棒，但 gitea 的开发人员不使用时，我会被嘲笑为他们自己的项目“...

这并不意味着批评或作为一种推动你们的方式。 只是让你知道我（可能还有很多其他人）在使用 gitea 作为主要源代码控制系统时会觉得麻烦；）

最后，要更有建设性。 如果您正在寻找一个非常好的（且便宜）的 clous vps 用于备份甚至托管 gitea，请查看 hetzner https://www.hetzner.com/storage/storage-box虽然对于像 Gitea 这样的重要基础设施您可能希望在两个完全不同的位置备份它（例如 hetzner 和 digitalocean）。

@markg85我们正在开发https://gitea.com

在 gitea.com 上托管 gitea 的任何更新？

@zachdoty仍在努力。

我忘记了从 github 迁移到 gitea 的必要条件。 我们需要移动所有数据（包括 git 数据、问题、评论、从 github 到 gitea 的拉取请求），但实际上我还没有找到合适的工具来做到这一点。 我已经发送了关于将存储库从前端迁移到后端的 PR，请参见 #6200 ，并且https://gitea.com/gitea/migrator应该合并到 gitea，因为 gitea 的 API 不允许创建指定索引号的问题。

gitea-github-migrator几乎可以迁移所有东西，以防你还没有找到。 如果缺少某些东西，也许可以在那里添加，因此其他项目也有一个很好的迁移工具。

@skddc它们实际上是相同的。

啊，对不起。 没有关注链接。

正如@kolaente所说，我们邀请@jonasfranz将gitea-github-migrator 移动到gitea.com，我发送了一个PR https://gitea.com/gitea/migrator/pulls/1想要改进它。 但是我发现作为第三方工具，有一个缺点。 那就是很难像以前一样保持问题索引。 （让关于该问题的所有链接仍然可用。）所以我认为将迁移工具合并到迁移 UI 上的 gitea 是一个更好的主意。

如果可以保留评论等中的内部链接，那肯定会很棒。 如果来自同一个 repo 的 PR 可以作为实际 PR 而不是问题导入，那也很棒！

我在问题内容上添加了新任务Migrate a throughout github repository to gitea并将其移至 1.9.0，这样就不会阻止 v1.8 的发布。 但我认为我们不应该等到 v1.9 发布，因为 gitea.com 将跟随大师。

Gitea.com 是否准备好生产，我是否应该担心将代码存储在那里而丢失？

@BNolet我们已经建立了一个 6 台机器的

哇，太棒了！ 你们都期望能够成为 GitHub 或 Gitlab 的全面替代品吗？

我不这么认为。 gitea.com 的主要目标是托管 gitea 的开发本身。 虽然我们对 gitea.com 没有做任何限制，但我们鼓励您设置自己托管的 Gitea 实例，因为它非常简单。

有什么理由不启用 OpenID 登录？

@lunny我有一个，我喜欢它：D

CI/CD 成为 Gitea 产品一部分的可能性有多大？

@strk忘了它。 将启用 OpenID 登录。
@BNolet Gitea本身将使用无人机作为主要 CI/CD。

在我对 Github 上的 go-gitea 应用程序进行权限请求后，尝试在登录页面上使用 Github oauth 选项时出现 500 错误。

我应该等一下看看旗舰实例吗？

@jakimfett这是一个已知问题。 你可以试两次就OK了。

@strk忘了它。 将启用 OpenID 登录。

@lunny，因为它今天仍然关闭，是否有可能有一个部署脚本一直关闭它？

@jakimfett这是一个已知问题...

使用问题编号进行编辑，我将在那里跟进。

_编辑：格式化_

Codeberg是一项基于https://codeberg.org/Codeberg/gitea。

Gitea 将托管在https://gitea.com/gitea/gitea 上，我们已将大多数其他软件包移至https://gitea.com/gitea ，并且 gitea 本身正在进行中。 Mirror 在任何其他基于 gitea 的服务上都是受欢迎的。

@lunny昨天评论：
Mirror 在任何其他基于 gitea 的服务上都是受欢迎的。

周末回来后，我会拼凑一个最新的镜子。

有关的：
某处是否有镜像列表，我是否将自己添加到其中，或者...？

@jakimfett没有，但是您可以使用新的文档页面创建公关

为了在将 gitea 迁移到 github 时获得更好的用户处理程序，我想将其移至 v1.10，我认为我们应该在开始迁移之前实现https://github.com/go-gitea/gitea/issues/7293 。

如果它不是在中国托管或激活电子邮件需要 10 分钟才能到达，我将完全支持这一举措。

如果它不是在中国托管或激活电子邮件需要 10 分钟才能到达，我将完全支持这一举措。

编辑：显然，我是不正确的。

从一些谷歌搜索，显然 gitea.com 的 IP 地址实际上是在日本，而不是中国。 该IP地址归阿里巴巴所有。

我们使用mailgun.org发送邮件。 我不知道为什么它会花10分钟。

我们捐赠的云提供商是中国的滴滴云，它提供了很多机器。 我们目前别无选择。

gitea.com 的第一个目的不会像 github.com 或 gitlab.com 那样成为服务。 它只会托管 gitea 本身，我们建议您实际上设置自己的 gitea 实例。

@programmerjake那是一个桥接服务器。

我不打算离开我的实例，但我不喜欢这个项目依赖于一家过去几乎没有声誉的中国公司捐赠的基础设施或搜索结果。 你真的不知道他们将来会做什么，或者如果你不实施 XY 或不做 ZA，或者他们是否有一天会离开，他们是否会要求减少捐款。
你可能知道你在做什么，我的担心只是谨慎，但你永远不会知道。

为什么中国公司会这样做，而美国公司不会呢？ :)

而且我是中国人，也许你应该小心。 有一天我可能会偷走你的代码。 :)

我想我在 2014 年和另外 3 个中国人一起创办 Gogs 时可能有这个计划。

我不打算离开我的实例，但我不喜欢这个项目依赖于一家中国公司捐赠的基础设施。 你真的不知道他们将来会做什么，或者如果你不实施 XY 或不做 ZA，或者他们是否有一天会离开，他们是否会要求减少捐款。
你可能知道你在做什么，我的担心只是谨慎，但你永远不会知道。

这完全是愚蠢的回答。
现在我可能会更开放，因为我是荷兰人，我们有点接受这一点。 你也应该试试。

只要这个项目是开源的，我认为你所说的任何事情都没有风险。
即使他们这样做了，这可能意味着分叉 Gitea，他们完全有权利，因为许可证只是允许这样做。

然而，美国……让我提醒你，由于中美之间的“贸易战”，Github 现在限制了它们的功能。 如果有的话，美国目前对自由软件开发的风险比中国更大。 哎呀，由于贸易战，

@lunny和开发

gitea.com 的第一个目的不会像 github.com 或 gitlab.com 那样成为服务。 它只会托管 gitea 本身，我们建议您实际上设置自己的 gitea 实例。

这是您将来可能考虑的事情吗？

只要这个项目是开源的，我认为你所说的任何事情都没有风险。

核心项目没有风险，但基础设施有。 无论他来自任何地方还是来自中国，都无法保证下个月会出现这个名不见经传、声名狼藉的捐赠者。 GitHub 会在这里很长一段时间，而且不会那么快去任何地方。

此外，如果整个基础设施转移到中国，整个用户群将因中美之间的困难而受到影响。

@lunny关于大约需要 10 分钟的电子邮件，在我的情况下，我的公司服务器有一个反垃圾邮件措施，它是一个“冷静”计时器（此处为 20 分钟），在此期间它将暂时拒绝来自未知来源的任何邮件。 因此，如果这是用户（我）第一次收到来自该域（例如 gitea.com）的电子邮件，那么我的服务器将响应“稍后尝试”并记住该用户/域组合。 下次 gitea.com 尝试在预期时间内发送我的邮件时，服务器会接受该邮件。
显然，我们配置了一些不需要冷静期的“可信来源”，例如 GMail、Hotmail 等。

各位，如果您希望在每个地区都有更多的基础设施，请在https://opencollective.com/gitea用您的钱包投票

@SuperSandro2000你知道Gitea 不是服务而是_产品_？ 您下载源代码，在您的服务器中编译 Gitea 并安装它。 Gitea 的托管无需任何连接。

如果他们要求减少捐款，如果您不实施 XY 或不做 ZA，或者他们有一天会离开。

无法保证下个月不知名的、声名狼藉的捐助者会在那里。

对此有几个回应：我们不会在一家信誉不佳的公司举办，Gitea 的领导已经信任这家公司。 如果他们停止提供赞助，或者不再是一家公司，我们可以选择，并且可以搬到其他地方。

由于中美之间的困难，整个用户群都将受到影响。

Gitea 团队很大一部分来自中国（但我们在其他各大洲也有维护人员），如果开发团队无法访问代码，那么用户群将受到影响，这就是为什么我们需要开发团队能够访问代码。 我们构建了 Gitea，因此每个人都可以使用它，即使是被 GitHub 禁止的用户（在最近 GitHub 的禁令浪潮之后，很多用户开始使用 Gitea）。

正如其他人所提到的，在世界各地的其他实例上都有代码库的镜像，并且由于 git，有一个对代码所做的所有更改的分类帐，因此每个人都可以看到所有更改。

关于透明度的说明：我已锁定此线程。 我不想停止这个对话，但是应该把它移到另一个地方，因为这个 github 票是关于需要对自托管软件进行哪些增强（而不是我们托管的地方）。