如何强制 GitLab 在开始新管道之前运行完整的管道？

Question

I have one runner associated with my project to avoid concurrent build. GitLab to process the complete pipeline before start a new one?

concurrent is set to = 1 (config file of the runner)

before_script:
  - echo %CI_COMMIT_SHA%
  - echo %CI_PROJECT_DIR%

stages:
  - createPBLs
  - build
  - package


create PBLs:
  stage: createPBLs
  script: 
    - md "C:\HierBauen\%CI_COMMIT_SHA%\"
    - xcopy /y /s "C:/Bauen" "C:/HierBauen/%CI_COMMIT_SHA%"
    - xcopy /y /s "%CI_PROJECT_DIR%" "C:\HierBauen\%CI_COMMIT_SHA%"
    - cd "C:\HierBauen\%CI_COMMIT_SHA%"
    - ./run_orcascript.cmd
  only:
  - tags
  - master

build:
  stage: build
  script:
  - cd "C:\HierBauen\%CI_COMMIT_SHA%"
  - ./run_pbc.cmd
  only:
  - tags
  except:
  - master

build_master:
  stage: build
  script:
  - cd "C:\HierBauen\%CI_COMMIT_SHA%"
  - ./run_pbcm.cmd
  only:
  - master

package:
  stage: package
  script:
  - cd "C:\HierBauen\%CI_COMMIT_SHA%"
  - ./cpfiles.cmd
  artifacts:
    expire_in: 1 week
    paths:
      - GitLab-Build
    name: "%CI_COMMIT_REF_NAME%"
  only:
  - tags
  - master

Unfortunately, the earlier started pipeline is disturbed by a new started pipeline. As a result, the build is flawed at the end...

EDIT new config file:

before_script:
  - echo %CI_BUILD_REF%
  - echo %CI_PROJECT_DIR%
  - xcopy /y /s "C:/Bauen" "%CI_PROJECT_DIR%"

stages:
  - createPBLs
  - build
  - package


create PBLs:
  stage: createPBLs
  script: 
    - ./run_orcascript.cmd
  only:
  - tags
  - master


build:
  stage: build
  script:
  - ./run_pbc.cmd
  only:
  - tags
  except:
  - master


build_master:
  stage: build
  script:
  - ./run_pbcm.cmd



  only:
  - master

package:
  stage: package
  script:
  - ./cpfiles.cmd
  artifacts:
    expire_in: 1 week
    name: "%CI_COMMIT_REF_NAME%"
    paths:
      - GitLab-Build
  only:
  - tags
  - master

Answer 1

Currently there is no way for this, and there is an open issue at the moment on GitLab.

What you can do instead is to add limit = 1 in your gitlab-runner config.toml file, which would enforce the gitlab-runner to only accept one job at a time.

I see that you are not passing artifacts between your stages, but if your build stage, depended on anything in the createPBLs stage, you can use a combination of artifacts and dependencies to pass data between stages.

---

For example:

before_script:
  - echo %CI_COMMIT_SHA%
  - echo %CI_PROJECT_DIR%

stages:
  - createPBLs
  - build
  - package


create PBLs:
  stage: createPBLs
  script: 
    - md "C:\HierBauen\%CI_COMMIT_SHA%\"
    - xcopy /y /s "C:/Bauen" "C:/HierBauen/%CI_COMMIT_SHA%"
    - xcopy /y /s "%CI_PROJECT_DIR%" "C:\HierBauen\%CI_COMMIT_SHA%"
    - cd "C:\HierBauen\%CI_COMMIT_SHA%"
    - ./run_orcascript.cmd
  artifacts:
    name: createPBLS_%CI_COMMIT_SHA%
    untracked: true
    expire_in: 1 day
  only:
  - tags
  - master

build:
  stage: build
  script:
  - cd "C:\HierBauen\%CI_COMMIT_SHA%"
  - ./run_pbc.cmd
  dependencies:
  - createPBLs
  artifacts:
    name: build_%CI_COMMIT_SHA%
    untracked: true
    expire_in: 1 day
  only:
  - tags
  except:
  - master

build_master:
  stage: build
  script:
  - cd "C:\HierBauen\%CI_COMMIT_SHA%"
  - ./run_pbcm.cmd
  dependencies:
  - createPBLs
  artifacts:
    name: build_%CI_COMMIT_SHA%
    untracked: true
    expire_in: 1 day
  only:
  - master

package:
  stage: package
  script:
  - cd "C:\HierBauen\%CI_COMMIT_SHA%"
  - ./cpfiles.cmd
  dependencies:
  - build_master
  artifacts:
    expire_in: 1 week
    paths:
      - GitLab-Build
    name: "%CI_COMMIT_REF_NAME%"
  only:
  - tags
  - master

Answer 2

Use the resource_group feature, which provides a way to group jobs which need the same mutex wrapped around them. Out of the box, resource_group s don't provide this pipeline-level mutexing (concurrency prevention), however, using the process mode option, specifically setting it to "oldest first", does. The docs further state that:

To change the process mode of a resource group, you must use the API and send a request to edit an existing resource group by specifying the process_mode:

 unordered oldest_first newest_first

Also mentioned here: https://stackoverflow.com/a/74286510/532621