Ask HN: Alternatives to GitHub
Ask HN: Alternatives to GitHub
Ask HN：GitHub 的替代方案
plqbfbv: To all of those proposing self-hosted GitLab: we did it for 6+ years in my company, and it’s not always a smooth sailing. We had our own runners and we made it auto-upgrade across docker images daily before business start. It mostly worked really well, except those few times were a Docker upgrade had to be rolled back, or that one time the bundled pg_shared_buffers was set at 1MB by default, making schema upgrades impossible for bigger instances, or a version major would break pipeline expectations forcing to upgrade 200+ repos at a time (we pinned to major afterwards). Lately I was also receiving an almost weekly “critical patch” newsletter due to critical/high vulnerabilities, which I can only imagine are due to LLM running over the code and identifying bugs.
plqbfbv： 对于所有建议自托管 GitLab 的人：我的公司已经这样做了 6 年多，但这并不总是一帆风顺。我们有自己的 Runner，并且在每天业务开始前通过 Docker 镜像进行自动升级。它大部分时间运行良好，除了那几次 Docker 升级不得不回滚，或者有一次捆绑的 pg_shared_buffers 默认被设置为 1MB，导致大型实例无法进行模式升级，又或者某个大版本更新破坏了流水线预期，迫使我们一次性升级 200 多个仓库（之后我们锁定了大版本）。最近，我几乎每周都会收到关于“关键补丁”的通讯，涉及严重/高危漏洞，我只能猜测这是因为 LLM 在代码上运行并识别出了漏洞。
That said, I wish we hadn’t migrated to GH, our self-hosted instance had WAY less downtime despite being perhaps a bit slower (mgmt saving money) and required a bit more toil: GH is nowhere near Enterprise-ready and it feels a downgrade across the board. GL has better access granularity, better docs, better integrations, and you can clearly see the UI received a lot of attention (although it does take 10m with a new account to pin the proper items in the maze of sub-menus that is the sidebar). You can also look at the code and help out if needed, and/or simply provide a patched version to your image via a docker mount.
话虽如此，我真希望我们当初没有迁移到 GitHub。我们的自托管实例停机时间要少得多，尽管可能稍微慢一点（管理层为了省钱），而且需要更多的人工维护：GitHub 远未达到企业级标准，感觉各方面都在降级。GitLab 拥有更好的访问粒度、更好的文档、更好的集成，而且你可以清楚地看到 UI 投入了大量精力（尽管新账号需要花 10 分钟才能在侧边栏那迷宫般的子菜单中找到并固定正确的项目）。你还可以查看代码并在需要时提供帮助，或者通过 Docker 挂载简单地为你的镜像提供补丁版本。
If you’re really looking at self-hosting GitLab for a smallish team (up to 50-100 ppl), prepare at the very least a 16GB machine (best 32GB) with 4 cores and a decent SSD, and at least a small team (1-3 people) that can maintain it properly or jump at it at any moment. For runners, a small k3s cluster is ideal to make use of all the resources you can throw at it without worrying about managing the runner state/configuration.
如果你真的打算为一个小团队（最多 50-100 人）自托管 GitLab，请至少准备一台 16GB 内存（最好 32GB）、4 核 CPU 和不错的 SSD 的机器，并至少配备一个小团队（1-3 人）来妥善维护它，或者随时准备应对突发状况。对于 Runner，一个小型的 k3s 集群是理想的选择，这样可以充分利用所有资源，而无需担心 Runner 状态/配置的管理。
inanothertime: Setting up custom GitLab runners can be cumbersome in the beginning! We faced that multiple times with various customer projects for which we were using GitLab.com managed repos. That’s why my colleague and I recently built a “GitLab Runners as a Service” [0] — simply use your self-managed GitLab or GitLab.com account to login, adding pipeline runners is a 1-click operation! Under the hood we provision a Hetzner machine for you runners and automatically connect your GitLab group or project to it. Happy to hear your feedback!
inanothertime： 设置自定义 GitLab Runner 在初期可能会很麻烦！我们在使用 GitLab.com 托管仓库的多个客户项目中多次遇到这种情况。这就是为什么我和同事最近构建了一个“GitLab Runners as a Service” [0] —— 只需使用你的自托管 GitLab 或 GitLab.com 账号登录，添加流水线 Runner 只需一键操作！在底层，我们为你配置了一台 Hetzner 机器作为 Runner，并自动将你的 GitLab 组或项目连接到它。期待听到你的反馈！
lclc: This is pretty cool and one of the few things I couldn’t find a viable alternative to in-house hosting so far. The only thing your “GitLab Runners as a Service” is missing is ISO 27001 (and optionally SOC 2) certification. That makes it again easier for your customer to get / maintain their ISO 27001.
lclc： 这非常酷，也是我目前在内部托管之外找不到可行替代方案的少数几件事之一。你的“GitLab Runners as a Service”唯一缺少的就是 ISO 27001（以及可选的 SOC 2）认证。这会让你的客户更容易获得/维护他们的 ISO 27001 认证。
cortesoft: I find the gitlab runner registration process a lot simpler than the github process, and a lot more flexible when you are self hosting the gitlab instance. We used kubernetes runners for both, and gitlab was clearly better. The worst part about the github runner setup is that there is no built in support for using your own cache if you are using github.com and want to run your own runners. In order to use your own cache store for your runner jobs, you have to patch the runner image because the cache location is hard coded. Gitlab lets you choose your cache location as a standard feature.
cortesoft： 我发现 GitLab Runner 的注册过程比 GitHub 的简单得多，而且在自托管 GitLab 实例时要灵活得多。我们两者都使用了 Kubernetes Runner，GitLab 明显更好。GitHub Runner 设置中最糟糕的部分是，如果你使用 github.com 并想运行自己的 Runner，它没有内置对使用自定义缓存的支持。为了在 Runner 作业中使用自己的缓存存储，你必须修补 Runner 镜像，因为缓存位置是硬编码的。而 GitLab 将选择缓存位置作为一项标准功能提供。
scientifik: ex-GitLabber here, and yes this is a pretty common scenario. GitLab as a product is pretty good, however GitLab Inc, is not great at supporting the broader community especially the SMB-Mid tier self-hosted users. (If you’re big enterprise you’ll get white glove support). It’s a bummer because they had so much potential to dethrone GitHub a few years ago but really missed the opportunity to position themselves as a viable alternative. That said I still use gitlab.com for my personal projects over anything owned by Microsoft.
scientifik： 前 GitLab 员工在此，是的，这是一个非常普遍的情况。GitLab 作为产品非常不错，但 GitLab 公司在支持更广泛的社区方面做得并不好，尤其是对于中小型的自托管用户。（如果你是大型企业，你会得到白手套式的支持）。这很遗憾，因为几年前他们非常有潜力取代 GitHub，但确实错失了将自己定位为可行替代方案的机会。话虽如此，我个人项目仍然使用 gitlab.com，而不是微软旗下的任何产品。
Lorin: As someone who used to submit issues to Gitlab just to see them stagnate for 6-8 years and then ceremonially get closed after being stuck in management/release bump hell (along with many ‘me toos’ from both Gitlab premium support staff / 3rd party contributors).
Lorin： 作为一个曾经向 GitLab 提交过 Issue 的人，我看到它们在 6-8 年的时间里停滞不前，然后在陷入管理/版本发布地狱后被仪式性地关闭（伴随着来自 GitLab 高级支持人员和第三方贡献者的许多“我也是”的附和）。