4、第一个Pipeline：编写简单的.gitlab-ci.yml、触发构建、查看构建日志

说实话，很多新手学CI/CD，第一步就卡在「怎么写配置文件」上。

我当年也一样。对着GitLab的文档看了半天，满屏的YAML语法，头都大了。

其实没那么复杂。说白了，.gitlab-ci.yml 就是一个告诉GitLab Runner「该干啥」的剧本。你写清楚步骤，它照着演就行。

4.1 先搭个最简单的架子

我个人习惯，第一个Pipeline不要搞太复杂。先跑通再说。

在项目根目录下，新建一个文件，名字必须是 .gitlab-ci.yml。注意前面有个点，别漏了。

stages:
  - build
  - test

job_build:
  stage: build
  script:
    - echo "正在编译代码..."
    - mkdir -p output
    - echo "编译完成" > output/build.log

job_test:
  stage: test
  script:
    - echo "正在运行测试..."
    - cat output/build.log
    - echo "测试通过！"

嗯，这里要注意：缩进必须用空格，不能用Tab。YAML对缩进极其敏感，我曾经因为一个空格不对，排查了半小时。

4.2 这些配置到底在说啥？

我来拆解一下上面的内容：

配置项	含义	我的理解
stages	定义流水线的阶段顺序	就像做菜，先切菜再炒菜，顺序不能乱
job_build	任务名称，可以随便起	我习惯用「动词_模块」的命名方式
stage	这个任务属于哪个阶段	必须跟stages里定义的一致
script	要执行的Shell命令	可以写多行，Runner会逐条执行

你想想看，这个结构其实很直观。每个job就是一个「工作单元」，它属于某个stage，然后执行一些命令。

4.3 触发构建：Push一下就搞定

配置文件写好了，怎么让它跑起来？

很简单。把代码推送到GitLab仓库就行。

git add .gitlab-ci.yml
git commit -m "添加第一个Pipeline配置"
git push origin main

Push完成后，打开GitLab的项目页面。你会看到左侧菜单有个 CI/CD → Pipelines 的入口。

点进去，就能看到你的Pipeline正在运行。状态会从 pending → running → passed。

4.4 查看构建日志：排查问题的命根子

Pipeline跑完了，怎么知道里面干了啥？

点进具体的job（比如 job_build），就能看到完整的日志输出。

日志里会显示：

• Runner拉取代码的过程
• 你写的每条echo命令的输出
• 命令的退出码（0表示成功，非0表示失败）
• 整个job的执行时长

我在项目中遇到过好几次，同事说「我的Pipeline挂了，不知道为啥」。我让他把日志贴出来，一看，原来是某条命令拼写错了。

4.5 避坑指南：我踩过的三个坑

讲几个我当年犯过的错，你遇到了能少走弯路：

1. 文件名大小写：.gitlab-ci.yml 必须全小写。我见过有人写成 .GitLab-CI.yml，结果GitLab根本不认。
2. Runner没注册：如果你用的是自建的GitLab，记得先注册Runner。否则Pipeline会一直卡在 pending 状态。
3. 缩进不一致：YAML里，script 下面的命令如果缩进不对，Runner会报语法错误。建议编辑器装个YAML插件。

4.6 核心逻辑：一张图看懂

为了让你更直观地理解整个流程，我画了张图：

这张图把整个流程串起来了。你从左边开始，写完配置，Push上去，Runner自动拉取并执行，最后去日志里看结果。

4.7 动手试试

现在你可以打开自己的项目，照着上面的配置写一个 .gitlab-ci.yml。Push之后，去Pipelines页面看看效果。

我第一次看到绿色的 passed 时，还挺有成就感的。虽然只是打印了几行字，但那种「自动化了」的感觉，确实不一样。

---

公众号:蓝海资料掘金营，微信deep3321