为单仓库轻松构建极狐GitLab CI/CD流水线

学习如何为单体仓库创建极狐GitLab CI/CD流水线，实现在单个仓库中托管多个应用程序。

单个仓库允许你将多个应用程序的代码存储在单一仓库中。在极狐GitLab中，这涉及将不同应用程序的源代码放置在同一个项目的独立目录中。虽然此策略支持代码的版本控制存储，但充分利用极狐GitLab CI/CD流水线能力曾颇具挑战性……直到现在！

理想情况：单体仓库中的CI/CD

由于仓库中包含多个应用程序的代码，你将需要多个流水线配置。例如，如果一个项目中同时存在.NET应用程序和Spring应用程序，每个应用程序可能需要完成不同的构建和测试作业。理想情况下，你可以完全解耦流水线，并仅在对特定应用程序的源代码进行更改时运行相应的流水线。

其技术方法是在项目级的.gitlab-ci.yml流水线配置文件中，根据特定目录的更改包含特定的YAML文件。.gitlab-ci.yml流水线充当控制平面，根据代码更改触发相应的流水线。

传统方法

在极狐GitLab 16.4之前，我们无法根据项目目录或文件的更改来包含YAML文件。但我们可以通过变通方法实现此功能。

在我们的单体仓库项目中，有两个不同应用程序的目录。此示例中，java和python目录分别代表Java和Python应用。每个目录都有一个特定于应用的YAML文件来构建各自的应用。在项目的流水线文件中，我们直接包含两个应用流水线文件，并将逻辑处理放在这些文件中。

.gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

top-level-job:
  stage: build
  script:
    - echo "Hello world..."

include:
  - local: '/java/j.gitlab-ci.yml'
  - local: '/python/py.gitlab-ci.yml'

在每个应用特定的流水线文件中，我们创建一个名为.java-common或.python-common的隐藏作业，仅在该应用的目录发生更改时运行。隐藏作业默认不运行，通常用于复用特定的作业配置。每个流水线继承该隐藏作业，以继承定义监视哪些文件更改的规则，从而启动流水线作业。

j.gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

.java-common:
  rules:
    - changes:
      - '../java/*'

java-build-job:
  extends: .java-common
  stage: build
  script:
    - echo "Building Java"

java-test-job:
  extends: .java-common
  stage: test
  script:
    - echo "Testing Java"

py.gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

.python-common:
  rules:
    - changes:
      - '../python/*'

python-build-job:
  extends: .python-common
  stage: build
  script:
    - echo "Building Python"

python-test-job:
  extends: .python-common
  stage: test
  script:
    - echo "Testing Python"

此方法存在一些缺点，包括必须为YAML文件中的每个其他作业继承该作业以确保其符合规则，导致大量冗余代码和人为错误空间。此外，继承的作业不能有重复的键，因此无法在每个作业中定义自己的规则逻辑，因为键会发生冲突且其值不会合并。

此方案的结果是：当java/更新时，运行包含j.gitlab-ci.yml作业的流水线；当python/更新时，运行包含py.gitlab-ci.yml作业的流水线。

新方法：条件包含流水线文件

在极狐GitLab 16.4中，我们为流水线引入了带rules:changes的include。此前，只能通过rules:if包含，而rules:changes的加入使此更新变得极为强大。现在，你可以直接在项目流水线配置中使用include关键字定义单个仓库规则。

新.gitlab-ci.yml:

stages:
  - build
  - test

top-level-job:
  stage: build
  script:
    - echo "Hello world..."

include:
  - local: '/java/j.gitlab-ci.yml'
    rules:
      - changes:
        - 'java/*'
  - local: '/python/py.gitlab-ci.yml'
    rules:
      - changes:
        - 'python/*'

然后，每个应用的YAML只需专注于构建和测试该应用的代码，无需重复继承隐藏作业。这为作业定义提供了更大灵活性，并减少了工程师的代码重写。

新j.gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

java-build-job:
  stage: build
  script:
    - echo "Building Java"

java-test-job:
  stage: test
  script:
    - echo "Testing Java"

新py.gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

python-build-job:
  stage: build
  script:
    - echo "Building Python"

python-test-job:
  stage: test
  script:
    - echo "Testing Python"

这实现了相同的目标：仅在其目录被修改时才包含Java和Python作业。实施时需注意：使用changes时作业可能意外运行。当向极狐GitLab推送新分支或新标签时，changes规则始终评估为true，因此首次推送到分支时，所有包含的作业都会运行，无论rules:changes如何定义。你可以通过先创建特性分支，然后打开合并请求开始开发来缓解此问题，因为创建分支时的首次推送会强制所有作业运行。

总之，单体仓库是可与极狐GitLab和CI/CD结合使用的策略，借助新的带rules:changes的include特性，我们有了更佳的使用极狐GitLab CI处理单体仓库的最佳实践。要开始使用单体仓库，请立即申请免费专业版试用。