为了开始GitLabPages，你应该使用一个项目模板，一个.gitlab-ci.yml模板，或者fork一个已经存在的示例项目。
因此，你没必要完全理解GitLabCI/CD就能部署你的网站。但是，有些情况下你需要编写你自己的或者调整现有的配置文件。这篇文章会带领你经历这个过程。
这篇文章也提供了一个全面而清晰的介绍来熟悉.gitlab-ci.yml文件并且来编写它。
GitLabCI/CD有许多的用途，从你的GitLab中通过持续集成，持续交付，和持续部署等方法来构建，测试，部署你的应用。你需要用GitLabPages来构建你的网站并且部署到静态页面服务器。
为了使用GitLabCI/CD，你要做的第一件事就是一份叫做.gitlab-ci.yml的配置文件放置在你的网站的根目录下。
这个文件的作用是告诉GitLabRunner去执行那些你会在命令行中执行的脚本。Runner就像你的终端一样工作，GitLabCI/CD告诉Runner去执行哪些命令。CI/CD和Runner都内置于GitLab中，你不需要设置额外的事情他们就能工作。
解析GitLabCI/CD的每个细节以及GitLabRunner不在本篇文章的范围内，但是为了能够编写我们自己的或者修改调整已经存在的.gitlab-ci.yml,我们需要理解一些基本的事情。这是一个YAML文件，有着自己的语法，你可以利用GitLabCILintTool工具来检验你的CI语法。1.实际例子想象下你有一个Jekyll网站，为了本地构建它，你需要打开你的终端，执行jekyllbuild。当然，在构建之前，你需要在你的电脑上安装Jekyll。为了安装，你需要打开你的终端执行geminstalljekyll。是这样吧？GitLabCI+GitLabRunner也是这样做，但是你只需要在.gitlab-ci.yml中编写你需要执行的脚本，这样GitLabRunner就会帮你做好这些事情。这看起来比实际上复杂一些.
你需要告诉Runner:
geminstalljekylljekyllbuild
1.1脚本Script一个YAML格式的脚本就像下面那样：
script:-geminstalljekyll-jekyllbuild
1.2任务Job到目前还好，每个脚本，在Gitlab中被一个job管理着，job是一系列你需要应用到指定Task上的脚本和设置
job:script:-geminstalljekyll-jekyllbuild
对于GitLabPage来说，job有一个特殊的名字，叫做pages,它告诉Runner你想要用GitLabPages部署你的网站：
pages:script:-geminstalljekyll-jekyllbuild
1.3Public目录我们也需要告诉Jekyll你想要把你的网站构建在哪里，并且GitLabPages只会考虑在public目录中的文件。对于Jekyll来说，我们需要指定一个标志位flag来指明构建网站的destination(-d)：jekyllbuild-dpublic，当然，我们需要告诉我们的Runner：
pages:script:-geminstalljekyll-jekyllbuild-dpublic
1.4Artifacts(有道翻译：史前古器物；人工产品？)我们也需要告诉Runner，这个job生成了artifacts,artifacts就是Jekyll构建的网站。artifacts存放在哪里呢？在public目录：
pages:script:-geminstalljekyll-jekyllbuild-dpublicartifacts:paths:-public
以上的脚本足够你用GitLabPages创建Jekyll网站了，但是从Jekyll3.4.0开始，它的默认模板创建命令jekyllnewproject需要Bundler来安装Jekyll的依赖和默认主题。为了调整我们的脚本来适应新的需求，我们只需要用Bundler来安装和构建Jekyll:
pages:script:-bundleinstall-bundleexecjekyllbuild-dpublicartifacts:paths:-public
就是这样，一个拥有以上内容的.gitlab-ci.yml会将你的Jekyll3.4.0版本的网站部署到GitLabPages，这是我们示例的最小配置。在接下来的步骤中，我们会添加额外的选项，提炼出新的脚本。
Artifacts会在GitLabPages页面部署之后被自动删除，你可以指定过期时间来保留artifacts一段时间。
1.5镜像Image到了这一步，你可能会问你自己："好吧，但是我需要Ruby来安装Jekyll，脚本中的Ruby在哪？"，这个问题很简单，在.gitlab-ci.yml中GitLabRunner找的第一件事就是Docker镜像，它制定了你的容器中需要什么环境来执行脚本:
image:ruby:2.3pages:script:-bundleinstall-bundleexecjekyllbuild-dpublicartifacts:paths:-public
在这个例子中，你告诉Runner去把包含Ruby2.3的镜像拉下来作为它文件系统的一部分。当你不指定镜像时，Runner会使用一个默认的镜像，是Ruby2.1.
如果你的SSG需要NodeJS来构建，你需要指定你想用哪个镜像，这个镜像应该包含NodeJS。例如，对于Hexo站点，你可以使用image:node：4.2.2
让我们继续
1.6分支Branching如果你使用GitLab作为版本控制平台，你项目中会有一些分支的的策略。意味着，你的项目中会有其他的分支，但是你想只有提交到默认分支(通常是master)才部署你的网站。为了实现这个，你需要在CI中添加另外一行，告诉Runner只在master分支执行叫做pages的job：
image:ruby:2.3pages:script:-bundleinstall-bundleexecjekyllbuild-dpublicartifacts:paths:-publiconly:-master
1.7阶段Stages另一个有意思的需要记住的概念是构建阶段stage.你的应用在部署到staging或者生产环境之前可以通过一系列的测试和其他任务。GitLab默认有三个stages:构建，测试和部署。为了指定你的job是在哪个stage执行，可以简单的添加一行：
image:ruby:2.3pages:stage:deployscript:-bundleinstall-bundleexecjekyllbuild-dpublicartifacts:paths:-publiconly:-master
你可能会有疑问："为什么我需要关心stage"，那是为了让你能够在部署你的网站到生产环境之前，去测试你的脚本并且检查构建出来的网站。你想要在你push到master的时候去执行测试脚本。很简单，在CI里添加一个job，让它在master分支之外的分支提交的时候，去执行测试：
image:ruby:2.3pages:stage:deployscript:-bundleinstall-bundleexecjekyllbuild-dpublicartifacts:paths:-publiconly:-mastertest:stage:testscript:-bundleinstall-bundleexecjekyllbuild-dtestartifacts:paths:-testexcept:-master
test的job在test阶段执行，Jekyll会在test目录构建站点，这个job会影响除了master之外的其它分支。
给不同的jobs分配stage最大的好处是，同一个stage的不同job会并行的执行。如果你的应用再部署之前需要多次的测试，你可以同时执行所有的测试，没必要等待一个测试跑完再执行下一个。当然这是GitLabCI和GitLabRunner的简短介绍，他们实际上更为强大。这就是为什么有能力为GitLabPages创建和调整你的构建过程。
1.8脚本执行前BefoScript为了避免在多个job中执行多次相同的脚本，你可以添加befo_script参数，在这你可以定义哪些命令你想让每一个job都执行。在我们的例子中，我们在pages和test的jobs中都执行了bundleinstall,没必要重复:
image:ruby:2.3befo_script:-bundleinstallpages:stage:deployscript:-bundleexecjekyllbuild-dpublicartifacts:paths:-publiconly:-mastertest:stage:testscript:-bundleexecjekyllbuild-dtestartifacts:paths:-testexcept:-master
1.9缓存依赖CacheDependencies如果你需要加速构建，缓存你项目中的依赖，那么可以使用cache参数，在我们的例子中，在执行bundleinstall时，我们缓存Jekyll这个依赖到vendor目录中：
image:ruby:2.3cache:paths:-vendor/befo_script:-bundleinstall--pathvendorpages:stage:deployscript:-bundleexecjekyllbuild-dpublicartifacts:paths:-publiconly:-mastertest:stage:testscript:-bundleexecjekyllbuild-dtestartifacts:paths:-testexcept:-master
这个例子中，我们需要在_config.yml文件中忽略掉/vendor目录，否则Jekyll会把它当做一个常规的目录在构建网站时进行编译：
exclude:-vendor
现在我们的GitLabCI不仅仅是构建我们的网站，而且会持续测试我们的功能分支的提交，缓存Bunder安装的依赖，并且根据每次master分支的提交，持续的部署我们的网站。
2.GitLabPages中的GitLabCI高阶指引你能用GitLabCI做的事情取决于你的创造力。一旦你习惯了，你可以开始创建极好的脚本来自动化的完成过去需要你手动完成的任务。阅读GitLabCI文档来了解怎么进一步的完善你的脚本。了解如何使用GitLabCIenvironment来部署你的网站到staging和生产了解如何串行的，并行的执行任务，或者创建一个自定义的pipeline拉取不同项目的指定目录来部署一个网站如何使用GitLabPages产出代码覆盖率报告转载请注明：http://www.0431gb208.com/sjszyzl/9193.html
