GitLab CI合并服务报错：无法解析数据库主机'db'

核心结论：大概率是配置合并逻辑或格式问题（非GitLab原生bug） #

你遇到的问题几乎可以确定是拆分后的配置合并未正确生效，而非GitLab的问题，以下是具体排查方向：

1. 检查include顺序与default段的合并优先级 #

GitLab CI对default段的合并规则是：

• 若多个include文件的default段包含不同键（比如一个有image，一个有services），会自动合并这些键；
• 但如果两个文件的default段存在相同键（比如都定义了services），则后引入的文件会覆盖前一个的对应配置。

举个反例：如果你的.gitlab-ci.yml是这样写的：

include:
  - .base.yml
  - .mariadb.config.yml

而.base.yml的default段里也定义了空的services: []，那.mariadb.config.yml的services会被覆盖，导致job无法找到db服务。

2. 验证.mariadb.config.yml的services格式正确性 #

确保你的服务别名配置格式完全正确，正确写法应为：

default:
  services:
    - name: mariadb:latest
      alias: db

如果写成简化格式services: [mariadb:latest]再单独加alias，或者格式缩进错误，都会导致别名不生效，job无法解析db主机。

3. 检查job是否显式覆盖了services #

如果你的job本身定义了services字段（哪怕是空数组services: []），会直接覆盖default段的services配置，导致db服务不被加载。比如：

test_job:
  script:
    - mysql -h db -u root -p password
  services: [] # 这里会覆盖default的services，导致找不到db

4. 确认GitLab版本兼容性 #

旧版本的GitLab（比如13.x及更早）对include的default段合并存在一些bug，比如数组类型的配置（如services）无法正确合并。如果你的GitLab版本较老，建议升级到14.x及以上版本测试。

快速验证方法 #

在.gitlab-ci.yml中添加一个临时job，输出当前生效的配置：

debug_config:
  script:
    - echo "$CI_CONFIG_PATH"
    - cat "$CI_CONFIG_PATH"

执行这个job后，查看输出的合并后配置，确认default段是否包含正确的services配置。如果合并后的配置里没有services或别名错误，就能直接定位到问题所在。

内容的提问来源于stack exchange，提问作者Darko Miletic