Travis CI的新定价计划给我的开源作品带来了麻烦

我刚刚花了6个小时将我的一些开源项目从Travis CI迁移到GitHub Actions，我想我应该暂停一下(这个项目已经进行了12个小时，可能还需要15-20个小时)来记录一些想法。

我不是那种吹毛求疵的人。在近十年的时间里，Travis CI让我能够构建-并维护-数百个开源项目，并保持了多年。

我已经为Raspberry Pi、PHP、Python、Drupal、Ansible、Kubernetes、MacOS、iOS、Android、Docker、Arduino等构建了项目。我建造的几乎每一个项目都立即与特拉维斯CI整合在一起。

如果没有这种测试，没有按计划运行测试的能力，我就会放弃这些项目中的大多数。但有了测试，我能够跟上多年来由位腐烂导致的构建失败，并更容易地审查PR。

从一开始，Travis CI就是为了与GitHub存储库集成而构建的，并提供免费的开源CI。它一度在黑客新闻(Hacker News)和其他地方因其文化和精神而获得铺天盖地的赞扬。

但随着时间的推移，其他CI系统变得越来越流行，直到2018年底，GitHub抛出了一个重磅炸弹--GitHub Actions，而Travis CI的前景似乎是这样的：

现在，为了更好地阐明事情到底在哪里变得越来越糟，我把特拉维斯·CI关于开源版本最重要的时刻整理了一下：

2012年：特拉维斯CI筹集了1.34亿美元，以支持爱的众筹活动中的业务运营，并推出了私人储存库的付费计划

2012-2020：我将200多个开源项目库集成到Travis CI测试和构建流程中。

2020年10月：我把我剩下的大约120条travis-ci.org的回复都移到了travis-ci.com上，这样它们就可以真正运行了。

2020年11月2日：我注意到我的版本都不工作了。我甚至在看到新的账单计划通知之前就用完了积分。

请注意，我们还没有赶上时间表的末尾。还有许多其他开源开发者和项目仍在使用Travis-ci.org，他们要么没有时间，要么没有动力迁移到Travis-ci.com(或者最好是其他地方)，每天积压的大量构建工作就证明了这一点：

那些和我一样，在过去几周里为了摆脱积压的地狱而迁移到Travis-ci.com网站的人现在意识到，在我们的1000分钟试用计划用完后，我们将不得不乞求额外的构建分钟：

我们将提供开放源码软件会议记录的分配，这些会议记录将根据具体情况进行审查和分配。如果您想申请这些积分，请向Travis CI支持部门提出申请，说明您愿意被考虑获得OSS分配。请包括：

您的帐户名和VCS提供商希望申请多少积分(构建分钟数)(如果您的积分再次用完，您可以重复此过程以请求更多积分或讨论续订金额)。

对不起，不过不用了，谢谢。我每天没有足够的时间每隔几天|几周|几个月发一封电子邮件请求额外的构建积分，这样我就可以继续维护我的开源项目了。

正如我前面所说的，我很感激特拉维斯·CI在过去十年里为我自己的成长和职业生涯带来的加速。还有很多其他服务为开源维护员提供慷慨的服务，我对此表示感谢，并尽我所能(通常是在我力所能及的范围内，在经济上)提供支持。

我只是担心，就像2015年谷歌(Google)关闭谷歌代码(Google Code)一样，这将对我们中的一些人所依赖、但没有考虑到的规模较小、维护较少的开源项目产生一些连锁影响。

我个人也知道，整个项目将占用我可以投入到免费开源工作中的大约四周的时间，这意味着在我的开源开发时间中，一个月的时间就会消失得无影无踪。不好玩，也不激励人。

我很幸运，在GitHub赞助商上有很多支持者，他们帮助我的工作更可持续，但大多数开源维护者要么只有我的一小部分支持，要么根本没有。

自从2019年1月被收购以来，这件事就一直是不祥之兆--特别是在现有的工程人员被裁掉之后。我已经开始使用GitHub Actions为CI而不是Travis CI构建较新的项目。

我曾计划在几年的时间里慢慢迁移，因为我的许多旧项目仍然有效，正在使用，但并未积极开发。

但特拉维斯·CI本月在没有任何事先通知的情况下采取的行动迫使我采取了行动，现在我正在进行一个可能需要2到4周的过程，以尽快将一切从特拉维斯·CI手中移走。在构建失败上拖延一个月会导致堆积如山的小问题，这真的会让我陷入困境。

不管怎样，我的悲伤故事说够了。我想链接到我用来迁移的一些工具，并展示我是如何自动化一些迁移的，这样您就可以更轻松地完成自己的迁移了！

我的大多数开源项目都是Ansible角色(我维护的Ansible内容的很大一部分)，为了让它们迁移，我尽可能地自动化。您可以在这期GitHub中看到所有细节：从Travis CI转换为GitHub操作。

对于每个角色，我都使用这本Ansible剧本来编写新的GitHub操作配置项，并使用模板发布工作流。然后，我调整了所有的值，这样操作就不会在每周的同一时间运行。

然后我创建了giHub-repo-manager，这是一个简单的小项目，它使用PyGithub在我的所有存储库或部分存储库中进行更改。我使用它将Galaxy_API_KEY密钥添加到我帐户中以Ansible-Role-*开头的所有存储库(对于个人帐户中的存储库，您必须将GitHub操作机密添加到每个存储库-对于组织，您可以创建共享的组织机密...。方便多了！)。

最后，我手动迁移了Travis CI构建定义中为每个角色定制的一小部分(例如，一些具有一维构建矩阵，一些具有二维构建矩阵，并且它们都具有不同的构建操作系统组合)。

我已经开始在GitHub操作的基础上构建许多新的项目(包括Ansible和Kubernetes相关的)，甚至还介绍了几次这个过程(例如，使用分子和GitHub操作进行持续的Ansible测试)。本周早些时候的消息让我加快了旧内容的迁移计划，从我有空的时候到现在。

幸运的是，GitHub Actions几乎做了我在Travis CI中能做的所有事情(到目前为止……。我还有36个独特的回复要做！)，我唯一真正抱怨的是继续出错功能不能替代Travis CI的Allowed_Failures选项。

还有一些工作要做，我正在努力安排事情的优先顺序，这样我就不会让我最广泛使用的项目(如Drupal VM)在太长时间内没有活动的CI，但至少这个故事不会有一个糟糕的结局。