使您的依赖关系保持最新是我们许多人都在努力解决的问题。当然,我们想要最新最好的。我们想要最新的安全修复。但是,开发人员的时间最好花在更有用的事情上,而不是每天检查依赖项是否有更新,以及此更新是否不会破坏当前的构建。

自动化流程

要解决此问题,您可以使用外部服务,例如greenkeeper或renovate。但在撰写本文时,两者都只与 GitHub 合作,当您使用他们提供的服务时。在翻新的情况下,可以选择使用他们的服务。他们保持 renovate](https://github.com/renovatebot/renovate)的[源代码开放,并允许每个人设置一个自托管的 renovate bot。这听起来很麻烦。租用新服务器,设置翻新,链接到 GitLab,设置 cron-job 或类似的东西来持续检查。

GitLab-CI 救援

[](https://res.cloudinary.com/practicaldev/image/fetch/s--G-p-0kf_--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:// /cdn-images-1.medium.com/max/2542/1%2AP2aylb0tE7ODbUlND17oQQ.png)GitLab-CI Pipeline View

GitLab](https://about.gitlab.com/product/continuous-integration/)的[CI 部分是我最喜欢的功能。对于我创建的每个存储库,我都会立即设置一个.gitlab-ci.yml。每当我将某些内容推送到存储库的任何分支时,都会测试代码,构建 docker 容器,并部署文档。通过手动激活部署作业,项目将被部署到生产服务器。 GitLab 的这一部分非常值得一试。

但现在到了有趣的部分。让我们使用 GitLab-CI 检查选择的存储库中是否存在过时的依赖项,并创建合并请求来更新它们。我们只需要创建一个包含三个文件的新存储库:

config.js 用于配置 renovate

    module.exports = {
     platform: ‘gitlab’,
     endpoint: ‘https://gitlab.com/api/v4/',
     assignees: [‘mikebarkmin’],
     baseBranches: [‘master’],
     labels: [‘renovate’],
     extends: [‘config:base’]
    };

repositories.txt 用于跟踪我们要检查的存储库

    openpatch/ui-core
    openpatch/template

.gitlab-ci.yml 运行更新的心脏

    image: docker:latest

    services:
      - docker:dind

    renovate:
      stage: build
      script:
          - docker run -e RENOVATE_TOKEN="$GITLAB_TOKEN" -v $PWD/config.js:/usr/src/app/config.js renovate/renovate:19 $(cat repositories.txt | xargs)
      only:
        - master

如您所见,我正在使用两个需要配置的 GitLabSecret CI 变量。 GITLAB_TOKEN 需要是个人访问令牌与范围 api 和 GITHUB_TOKEN 需要是个人访问令牌与范围回购。

现在一切都结束了。当您运行管道时,renovate 将检查 repositories.txt 中的存储库,并在需要更新依赖项时创建合并请求。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--76ztL626--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cdn-images -1.medium.com/max/2554/1%2AkAJqSk45_mE2HISVcjvbSQ.png)Pipeline Schedule Overview

最后,我们可以创建一个管道计划以每隔 x 小时或 x 天或任何您喜欢的方式运行管道。

要执行此设置,可以访问我们的 Patcher 存储库:https://gitlab.com/openpatch/patcher

总结

[合并请求](https://res.cloudinary.com/practicaldev/image/fetch/s--Rzul99RU--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cdn- images-1.medium.com/max/2524/1%2ANVewoZL3fkvwljmuFz25Aw.png)Renovate 的合并请求

我们创建了一种使用 GitLab-CI 自动更新依赖项的方法。我们现在只需要继续等待合并请求,看看我们的测试套件是否成功。之后我们可以愉快地合并(假设您的测试套件非常好)。如果你真的信任你的测试套件,你甚至可以让 renovate 自动合并请求,如果管道成功的话。我们能做的最后一件事是为 renovate-task 创建一个单独的用户。我希望你们现在都可以优化您的工作流程,并且永远(好吧,很可能永远不会)不必担心再次更新您的依赖项。