从Jenkins Ci Service迁移到gitlab-ci.yml

Question

到目前为止，我们使用Jenkins在基于Jenkins CI service的任何功能分支上运行我们的构建。我们目前正在试验基于gitlab-ci.yml的管道。作为一个起点，我想限制这只是由少数开发人员创建的特定分支作为beta测试。

我试图避免将.gitlab-ci.yml从feature分支合并到基于.gitattributes和merge策略的release分支(参见here)，但这迫使我在release分支中使用.gitlab-ci.yml。因此，gitlab强制我拥有一些有效的yml内容(我希望我至少可以将其保留为空)，否则我将获得无效的yml失败。

是否建议将.gitlab-ci.yml仅保留在feature分支上，并避免手动步骤以避免合并.gitlab-ci.yml文件，直到我们将其应用于所有分支？

类似的问题：

https://forum.gitlab.com/t/how-to-ignore-gitlab-ci-yml-file-when-merging-the-branches/17948

GitLab merge behavior - keep file from branch

Answer 1

在Bertrand响应之后，只要管道只在选定的merge请求上执行，我实际上并不关心在release分支中有.gitlab-ci.yml。我更改了我的.gitlab-ci.yml以包含一条规则。根据下面的逻辑，管道将仅在分支名称格式为FTR-ddddd g的合并请求上执行

image: maven-mta:latest
variables:
  GIT_DEPTH: 0
Unit tests and Sonar Check:
 script:
    - mvn clean verify sonar:sonar
  artifacts:
    reports:
      junit:
        - "*/target/surefire-reports/TEST-*.xml"
  allow_failure: false
  rules:
    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^FTR-\d+-gl/ && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
      when: always
  tags:
  - sonarqube
  - docker

我在满足Jenkins CI服务未运行的条件的合并请求上得到了意想不到的副作用(实际上我很喜欢)。不幸的是，我没有找到任何支持这种行为的文档，下面的page建议在使用gitlab ci时禁用Jenkins CI。

Answer 2

“作为起点，我想将此限制为仅针对特定分支”

您可以使用唯一的标记。

  only:
    - feature-*