我们有几个Jenkins示例，有超过400个工作。虽然它被用作CI工具，但由于所有集成和服务的数量，它相当复杂。我们有三个仓库与Jenkins一起使用：
1.具有作业定义的作业DSL
1.与大多数（Jenkinsfiles中定义了许多自定义管道）管道定义共享库
- JCasC
虽然我完全支持进步，但我有点不愿意过渡到Github Actions，因为它不仅需要花费大量时间，而且Jenkins实现的复杂性可能不会那么容易通过Github Actions实现。尽管如此，管理层已经决定削减Jenkins维护的成本。
任何走上这条路的人，它看起来很复杂吗？你是否设法用GH实现了与Jenkins相同的定制和抽象水平？
我有使用Github Actions的经验，但限于较小的应用程序，而且我绝对没有复杂系统的GH经验。
1条答案
按热度按时间dsekswqp1#
虽然从Jenkins迁移到GitHub Actions是officially documented（并且，正如the comments中的Benjamin W所指出的，辅助by automatic import），但它会带来以下困难：
1.代码访问：Jenkins是自托管的，可以访问自托管的代码。
除非您的代码已经在GitHub上，否则GitHub Action将无法访问相同的自托管代码以在其运行器上检出它。
使用GHE (GitHub for Enterprise)，您可以使用self-hosted runner ...但这将等同于您当前的Jenkins设置。
简单地将代码托管在GitHub上并不总是可以用于机密的专有企业代码。
1.出版物：GitHub Action可以存储其管道as an artifact的结果。同样，根据企业项目的敏感性，这可能是也可能是不可接受的。