git/gitflow/gitlib>> gitlab-job-guard>> 返回
项目作者： shalomb

项目描述 ：
Guard gitlab CI jobs from multiple simultaneous executions
高级语言： Python
项目地址: git://github.com/shalomb/gitlab-job-guard.git
创建时间： 2019-04-15T21:09:40Z
项目社区：https://github.com/shalomb/gitlab-job-guard
开源协议：Apache License 2.0
下载


pipeline status

gitlab-job-guard

Guard pipeline jobs from multiple simultaneous executions

  1. $ PRIVATE_TOKEN="$GITLAB_API_TOKEN" gitlab-job-guard -w 3600
  2. $ my-unguarded-deployment-task --to=production

gitlab-job-guard will block if it detects other pipelines running for
the current project to avoid multiple pipelines from clobbering up a
deployment/environment.

While gitlab will auto-cancel redundant, pending pipelines for the same branch
by default - this is not the case for multiple pipelines from different
branches targeting a particular deployment/environment. Gitlab has no way to
detect or control these user-defined branch-to-environment mappings and this
means environments can easily be left in an unsafe/broken state. (e.g.
terraform apply or ansible, etc from different pipelines running at the same
time).

gitlab-job-guard uses the Gitlab API to determine if existing pipelines are
scheduled and to backoff-and-retry until it is safe to proceed. Conflicts
are detected by user-defined matches on pipeline ref names (branch, tag, etc)
and/or pipeline status.

Usage

The simplest usage would likely be placing gitlab-job-guard in a
before_script section in your gitlab-ci.yml to protect all jobs (though this
can slow things down).

  1. before_script:
  2.   - PRIVATE_TOKEN="$GITLAB_API_TOKEN" gitlab-job-guard

Though often, this is only needed to guard jobs that share common state/data
(i.e. a deployment environment, an artifact build/release, etc).

  1. deploy-production:
  2.   stage: deploy
  3.   script:
  4.     - PRIVATE_TOKEN="$GITLAB_API_TOKEN" gitlab-job-guard
  5.     - my-unguarded-deployment-task --to=production

or to guard something like a terraform job running for tags.

  1. provision-infrastructure:
  2.   stage: provision
  3.   script:
  4.     - export PRIVATE_TOKEN="$GITLAB_API_TOKEN"
  5.     - gitlab-job-guard --guard-ref-regex='^v[0-9\.]+'  # Regex matches tags
  6.     - terraform plan  ...
  7.     - terraform apply ...
  8.   only:
  9.     - tags

Other usages

To hold jobs for a collisions on pattern matches on the ref/branch name.

  1. gitlab-job-guard -c=^master$                # Match branch names matching 'master' exactly
  3. gitlab-job-guard -c=^(master|dev(elop)?)$   # Match any of the mainline branches
  5. gitlab-job-guard -c=^(feature|release|hotfix)/  # Match any gitflow transient branch prefixes
  7. gitlab-job-guard -c=^[0-9]\-                # Match branch names beginning with a number
  8.                                             # and dash ignoring all other text.
  9.                                             # e.g. a gitlab branch made from an issue
  11. gitlab-job-guard -c=^v?[\d.]+$              # Match (semver) tags like v1.0.9, 2.0
  13. gitlab-job-guard -c=^environment/           # Match any environment deployments?
  15. gitlab-job-guard -c=^environment/dc1.+      # Match environment deployments to DC1?
  17. gitlab-job-guard -c="$CI_BUILD_REF_NAME"    # Match current branch name (partially).
  18.                                             # i.e. 'master' matches 'feature/master-document'
  20. gitlab-job-guard -c="^$CI_BUILD_REF_NAME$"  # Match current branch name (exactly).
  21.                                             # i.e. 'master' does not match 'master-deployment'
  23. gitlab-job-guard -c='.+' -s='running|pending'  # Match any pipeline in running or pending state

To hold a job for a collision on part of the ref name (e.g. on branch prefix
such as feature/ or hotfix/ or release/, etc a la gitflow).

  1. # Assuming CI_BUILD_REF_NAME=feature/foo
  3. CI_BUILD_REF_PREFIX=$(echo "$CI_BUILD_REF_NAME" | sed -r 's@(.+/)(.+)@\1@')
  4. # CI_BUILD_REF_PREFIX now contains 'feature/'
  6. gitlab-job-guard -c="^$CI_BUILD_REF_PREFIX" -s='running|pending'

TODO

For long pipelines, this solution can have subtle consequences with growing
queues and increased contention and unpredictability as to which pipeline is
the first-past-the-post. An older pipeline taking precedence over newer commits
if often not desired and newer pipelines always winning is probably desired.

  • Handle existing conflicting pipelines - cancel them or give-way.
  • Narrow down conflicts to jobs (CI_JOB_NAME) or stages (CI_JOB_STAGE)
    so that other parts of the pipelines that do not share state are allowed to
    run freely.