20. 修改完毕，回到values.yam所在目录，执行以下命令即可创建GitLab Runner： helm install \ --name-template gitlab-runner \ -f values.yaml . \ --namespace gitlab-runner
检查pod是否正常：
22. 看pod日志也并未发现异常：
23. 回到GitLab的runner页面，可见新增一个runner：
至此，整个GitLab CI环境已部署完毕，接下来简单的验证环境是否OK； 验证
在GitLab仓库中，增加名为.gitlab-ci.yml的文件，内容如下：
# 设置执行镜像 image: busybox:latest # 整个pipeline有两个stage stages: - build - test # 定义全局缓存，缓存的key来自分支信息，缓存位置是vendor文件夹 cache: key: ${CI_COMMIT_REF_SLUG} paths: - vendor/ before_script: - echo "Before script section" after_script: - echo "After script section" build1: stage: build tags: - k8s script: - echo "将内容写入缓存" - echo "build" > vendor/hello.txt test1: stage: test script: - echo "从缓存读取内容" - cat vendor/hello.txt提交上述脚本到GitLab，如下图，可见pipeline会被触发，状态为pending是因为正在等待runner创建executor pod：
3. 稍后就会执行成功，点开看结果：
4. 点开build1的图标，可见此job的输出信息：
5. 点开test1的图标，可见对应的控制台输出，上一个job写入的数据被成功读取：
至此，GitLab Runner已经成功在kubernetes环境部署和运行，接下来的文章，我们会一起实战将SpringBoot应用构建成docker镜像并推送到Harbor；
你不孤单，欣宸原创一路相伴Java系列
Spring系列
Docker系列
kubernetes系列
数据库+中间件系列
DevOps系列
欢迎关注公众号：程序员欣宸微信搜索「程序员欣宸」，我是欣宸，期待与您一同畅游Java世界...
https://github.com/zq2599/blog_demos