Bob's Blog

遇到这个场景：gitlab配置了CI。当用户A提交了代码，自动触发了一个job在pipeline中运行；几乎同时，用户B也提交了一份代码，也触发了一个job在pipeline中运行。job的运行需要一定时间，于是job A和job B在同一时间段都用到了一个环境，分别创建出的数据对另一个job产生了影响，于是都失败了。于是需要限制这种同一时间段的共同运行，job B后提交，那么等job A运行完毕后才开始执行。

在gitlab配置runner时，可以将concurrency和runner的limit的值设置为1，但runner个数往往不为1，仍然可能出现job A和job B同一时间段执行的情况。也不能总要求用户必须检查是否有正在运行的job。

查阅资料后，发现在.gitlab-ci.yml中添加resource_group即可。

比如下面的样例就是限定了同一时间只能有一个job unit_test存在，其他的就会等待：

stages:
  - test
  - deploy

unit_test:
  resource_group: unit_test  # 这里.. 省略了其他的信息
  image:
  stage: test
  before_script:
  script:
    - pytest
  coverage: '/TOTAL.*\s+(\d+%)$/'

deploy_qa:
  stage: deploy
  image:
  before_script:
  script:
  only:
    refs:
      - master

• resource_group: $CI_ENVIRONMENT_NAME ... 限制环境
• resource_group: $CI_JOB_NAME ... 限制job执行
• resource_group: $CI_COMMIT_REF_NAME:$CI_JOB_NAME ... 限制分支上的job执行
• resource_group: $CI_COMMIT_REF_NAME:$CI_ENVIRONMENT_NAME ... 限制相关分支的环境
• resource_group: $CI_PROJECT_NAME ... 限制了整个pipeline(放stages前)

当使用后，就会看到，几乎同时启动的job只会有一个运行，另一个就会等待前一个的unit_test执行完成后才开始，如下图：

参考：

https://gitlab.com/gitlab-org/gitlab-foss/-/issues/20481

https://gitlab.com/gitlab-org/gitlab/-/issues/15536