跳到内容

为GitLab页面创建和调整GitLab CI/CD

GitLab CI从GitLab开始构建、测试和部署你的应用持续集成、持续交付和持续部署方法。您将需要它来使用GitLab Pages构建网站，并将其部署到Pages服务器。

要实现GitLab CI/CD，我们需要的第一件事是一个名为.gitlab-ci.yml放置在你网站的根目录。

这个文件实际做的是告诉GitLab跑步像从命令行那样运行脚本。Runner充当您的终端。GitLab CI/CD告诉Runner要运行哪些命令。这两个都是内置在GitLab中的，您不需要设置任何东西就可以让它们工作。

解释GitLab CI的每一个细节和GitLab Runner超出了本指南的范围，但是我们需要了解一些东西才能编写我们自己的程序.gitlab-ci.yml或者修改一个现有的。这是一个Yaml文件，有自己的语法。方法检查CI语法GitLab CI Lint Tool．

实际的例子

假设你有一个变身怪医网站。要在本地构建它，您需要打开终端并运行哲基尔构建．当然，在构建它之前，你必须在你的电脑上安装Jekyll。为此，您必须打开终端并运行Gem安装jekyll．对吧?GitLab CI + GitLab Runner做同样的事情。但是你需要写在.gitlab-ci.yml您想要运行的脚本，以便GitLab Runner为您执行。看起来比实际复杂多了。你需要告诉跑步者的事情:

安装jekyll$ jekyll构建

脚本

将这个脚本转置到Yaml，它将像这样:

脚本：-Gem安装jekyll-哲基尔构建

工作

到目前为止一切顺利。现在,每个脚本，在GitLab中是由一个工作，这是一堆你想应用到特定任务的脚本和设置。

工作：脚本：-Gem安装jekyll-哲基尔构建

对于GitLab Pages，这个工作有一个具体的名字，叫什么页面，它告诉Runner你想要这个任务用GitLab Pages部署你的网站:

页面：脚本：-Gem安装jekyll-哲基尔构建

的公共目录

我们还需要告诉Jekyll你希望网站建在哪里，而GitLab Pages将只考虑名为公共．要在Jekyll上做到这一点，我们需要添加一个标志，指定目的地(- d）所建网站:Jekyll build -d public．当然，我们需要告诉我们的Runner:

页面：脚本：-Gem安装jekyll-Jekyll build -d public

工件

我们还需要告诉奔跑者工作生成工件，这是Jekyll建立的网站。这些工件存储在哪里?在公共目录:

页面：脚本：-Gem安装jekyll-Jekyll build -d public工件：路径：-公共

上面的脚本足以用GitLab Pages构建Jekyll站点。但是，从Jekyll 3.4.0开始，它的默认模板起源于Jekyll新项目需要打包机来安装Jekyll依赖项和默认主题。为了调整我们的脚本以满足这些新的需求，我们只需要使用Bundler安装和构建Jekyll:

页面：脚本：-包安装-Bundle exec jekyll build -d public工件：路径：-公共

就是这样!一个.gitlab-ci.yml使用上述内容将使用GitLab Pages部署您的Jekyll 3.4.0站点。这是我们示例的最小配置。在下面的步骤中，我们将通过向GitLab CI添加额外选项来改进脚本。

一旦GitLab页面被部署，工件将被自动删除。您可以通过指定过期时间来在有限的时间内保存工件。

图像

此时，您可能会问自己:“好吧，但是要安装Jekyll，我需要Ruby。Ruby在剧本上写得怎么样了?”答案很简单:GitLab Runner将在您的.gitlab-ci.yml是一个码头工人Image指定你在容器中需要什么来运行脚本:

图像：ruby: 2.3页面：脚本：-包安装-Bundle exec jekyll build -d public工件：路径：-公共

在本例中，您告诉Runner提取这个映像，该映像包含Ruby 2.3作为其文件系统的一部分。如果在配置中没有指定此映像，则Runner将使用默认映像，即Ruby 2.1。

如果你的SSG需要NodeJS为了构建，您需要指定想要使用的映像，并且该映像应该包含NodeJS作为其文件系统的一部分。例如，对于一个Hexo网站，您可以使用图片:节点:4.2.2．

注意:我们并不试图解释Docker映像是什么，我们只需要用最小可行的解释来介绍这个概念。要了解更多关于Docker映像的信息，请访问Docker映像的网站或查看Docker映像总结了解释在这里。

让我们再深入一点。

分支

如果您使用GitLab作为版本控制平台，您就可以在项目上使用分支策略。这意味着，您将在项目中有其他分支，但您只希望将其推到默认分支(通常主)部署到你的网站。为此，我们需要向CI中添加另一行，告诉Runner只执行该操作工作被称为页面在主分支只有：

图像：ruby: 2.3页面：脚本：-包安装-Bundle exec jekyll build -d public工件：路径：-公共只有：-主

阶段

另一个需要记住的有趣概念是构建阶段。你的web应用可以通过大量的测试和其他任务，直到它被部署到登台或生产环境。在GitLab CI上有三个默认阶段:构建、测试和部署。要指定您的工作正在运行，只需添加另一行到您的CI:

图像：ruby: 2.3页面：阶段：部署脚本：-包安装-Bundle exec jekyll build -d public工件：路径：-公共只有：-主

你可能会问自己:“我为什么要为阶段而烦恼?”那么，假设您希望能够在将站点部署到生产环境之前测试脚本并检查构建的站点。您希望运行的测试与您的脚本在执行时所做的完全相同主．这很简单，让我们添加另一个任务(工作)到我们的CI，告诉它测试每一个推送到其他分支，除了的主分支机构:

图像：ruby: 2.3页面：阶段：部署脚本：-包安装-Bundle exec jekyll build -d public工件：路径：-公共只有：-主测验：阶段：测验脚本：-包安装-Bundle exec jekyll构建-d测试工件：路径：-测验除了：-主

的测验约伯正在舞台上奔跑测验， Jekyll将在一个名为测验，该作业将影响除主．

申请的最大好处阶段对不同的工作同一阶段的每个作业都是并行构建的。所以，如果你的web应用在部署之前需要多个测试，你可以同时运行所有的测试，没有必要等待一个测试完成再运行另一个。当然，这只是对GitLab CI和GitLab Runner的简单介绍，它们是功能强大得多的工具。这是您为GitLab Pages站点创建和调整构建所需要的。

之前的脚本

避免在您的工作时，可添加该参数before_script，您可以在其中指定要为每个命令运行哪些命令工作．在我们的示例中，注意我们运行包安装对于这两份工作，页面而且测验．我们不需要重复它:

图像：ruby: 2.3before_script：-包安装页面：阶段：部署脚本：-Bundle exec jekyll build -d public工件：路径：-公共只有：-主测验：阶段：测验脚本：-Bundle exec jekyll构建-d测试工件：路径：-测验除了：-主

缓存的依赖关系

如果您想为项目依赖项缓存安装文件，以便更快地构建，您可以使用该参数缓存．对于本例，我们将把Jekyll依赖项缓存到供应商目录包安装：

图像：ruby: 2.3缓存：路径：-供应商/before_script：-捆绑安装——path供应商页面：阶段：部署脚本：-Bundle exec jekyll build -d public工件：路径：-公共只有：-主测验：阶段：测验脚本：-Bundle exec jekyll构建-d测试工件：路径：-测验除了：-主

对于这种特殊情况，我们需要排除/供应商从哲基尔_config.yml文件，否则Jekyll会将其理解为与站点一起构建的常规目录:

排除：-供应商

好了!现在我们的GitLab CI不仅构建了我们的网站，而且连续测试推送到特征分支，缓存与Bundler一起安装的依赖项，以及持续部署每一次推到主分支。

用于GitLab页面的高级GitLab CI

使用GitLab CI可以做什么，很大程度上取决于您的创造力。一旦您习惯了它，您就可以开始创建出色的脚本，使过去手动执行的大多数任务自动化。通读GitLab CI文档以了解如何进一步编写脚本。

Baidu
map