完事后，我们在gitlab->xxxProjct中就能找到该runner：
接下来，就可以定义项目构建流程了。项目的构建流程是由项目根目录的.gitlab-ci.yml文件控制的。当然了，一个pipeline可以涉及到多个runner。
.gitlab-ci.yml定义一个pipline，以下为示例
variables: DOCKER_TLS_CERTDIR: "/certs" # stage也可以自定义 stages: - build jar # - test - build and run image #job's name 可以随意取 buildJar: stage: build jar variables: # 若要使cache生效，须指定-Dmaven.repo.local MAVEN_OPTS: "-Dmaven.repo.local=.m2" cache: key: ${CI_COMMIT_REF_SLUG} paths: - .m2 only: - dev script: # package 已包含 test 步骤，所以流程中不需要另外配置test job - mvn clean package tags: - inkscreen_api artifacts: paths: - target/admin.jar expire_in: 3600 seconds deploy: stage: build and run image image: docker:stable services: - docker:dind only: - dev variables: IMAGE_NAME: newton/inkscreen-api:$CI_COMMIT_REF_NAME PORT: 38082 script: - docker build --build-arg JAR_PATH=target/admin.jar -t $IMAGE_NAME . - docker run -p $PORT:$PORT -d --name inkscreen-$CI_COMMIT_REF_NAME --env spring.redis.host=myredis $IMAGE_NAME tags: - inkscreen_apicache
cache常用在dacker-based job之间传递文件。比如项目依赖的公共jar包，jobA辛辛苦苦从网上down了下来，结果运行完了，jobA所在容器也跟着被移除，自然里面的所有文件都不存在了。后续其它job用到相同的jar包还要重新下载。同样的，pipline多次执行，jobA自己每次也要重新下载。
为了解决这个问题，gitlab-ci采用了cache的方式。指定文件/目录，每次job结束前将其打包，放到/etc/gitlab-runner/config.toml中对应的[runners.docker][volumes]指定的卷内，其它job（包括自己）运行前，对应的cache都会被加载并解压到容器内。
artifacts
artifacts是job生成的中间产物，会以压缩包（.zip）的形式生成。它会自动上传到gitlab服务器，the artifacts will be downloaded and extracted in the context of later stages。所以它和cache很像，但是设计它们的初衷是不同的。
Don't use caching for passing artifacts between stages, as it is designed to store runtime dependencies needed to compile the project:
cache: For storing project dependencies
Caches are used to speed up runs of a given job in subsequent pipelines, by storing downloaded dependencies so that they don't have to be fetched from the internet again (like npm packages, Go vendor packages, etc.) While the cache could be configured to pass intermediate build results between stages, this should be done with artifacts instead.
artifacts: Use for stage results that will be passed between stages.
Artifacts are files generated by a job which are stored and uploaded, and can then be fetched and used by jobs in later stages of the same pipeline. In other words, you can't create an artifact in job-A in stage-1, and then use this artifact in job-B in stage-1. This data will not be available in different pipelines, but is available to be downloaded from the UI.
The name artifacts sounds like it's only useful outside of the job, like for downloading a final image, but artifacts are also available in later stages within a pipeline.
另外，同样key的cache会被覆盖，而artifacts一旦生成就固定了，当然我们可以设置expire_in，过期删除之。
可参看各类语言/平台的.gitlab-ci.yml模板
实战我们定义一个最简单的pipline：第一步编译生成jar包，第二步将jar包导入docker镜像并运行，在某些环节还需加入代码review。因为最后我们会以docker容器运行jar包，所以这里不建议docker-based runner/executor的形式，因为该形式导致Docker-in-Docker的场景，带来可能的一些麻烦且难以解决的问题(比如内嵌容器如何关联外部服务以及对外提供服务)。所以我们直接宿主机安装GitLab Runner。
如果一定要以docker-based形式，那么可参看使用GitLab CI和Docker自动部署SpringBoot应用。在该文中，并没有在runner所在宿主机中运行容器，而是将生成的镜像发布到镜像仓库，再登录目标服务器拉取镜像运行，所以不存在Docker-in-Docker的麻烦事。
安装&注册[GitLab ]Runner # 1.Add the official GitLab repository curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash # 2.Install the latest version of GitLab Runner export GITLAB_RUNNER_DISABLE_SKEL=true; sudo -E yum install gitlab-runner