登录
当前位置： 首页 > 工具软件 > Drone-CI > 使用案例 >

gitlab-ci配置

张和颂
2023-12-01

.gitlab-ci.yml 示例

本文示例的k8s配置文件路径：

  • 项目：project1
    • src/
    • k8s/
      • st-testing.yaml
      • staging.yaml
      • ka-testing.yaml
      • st-mock.yaml
      • ka-staging.yaml
    • .gitlab-ci.yml
    • Dockerfile
    • Dockerfile.dev
    • Dockerfile.prod
    • Dockerfile.testing
    • …
# 这里自定义字段，在后文中使用
variables:
  # drone.yml repo: "hbdev.wataru.com/wataru/fe-site-staging"
  # DOCKER_IMAGE_NAME是repo的地址中，除去域名的剩下部分
  # drone.yml - kubectl apply -f ./k8s/st-mock.yaml -n wataru
  # xx_K8S_NAMESPACE 是 -n 后的值，-n指 -namespace
  # xx_DEPLOYMENT_NAME 在drone.yml中的 - kubectl rollout restart deployment fe-site-mock -n wataru 查看 “deployment”后的“fe-site-mock”就是 deployment_name

  # 在harbor官网建立自己的仓库，比如示例：hbdev.wataru.com，在仓库下建立目录wataru,将本次镜像上传到https://hbdev.wataru.com/wataru/下
  # 在这里区分了三种版本：1、标准版（通用版本）2、私有化版（为专门的客户精细功能）3、演示版（数据都是虚拟的，只展示UI和交互）
  # 标准版：正式环境、预发环境、测试环境
  #   正式：harbor.wataru.com/wataru/fe-site:1.1.1
  #   预发：harbor.wataru.com/wataru/fe-site:staging
  #   测试：hbdev.wataru.com/wataru/fe-site:testing
  # 私有化版：正式环境、预发环境、测试环境
  #   正式：harbor.wataru.com/wataru/fe-site-staging:1.1.1-ka
  #   预发：hbdev.wataru.com/wataru/fe-site-staging:staging
  #   测试：hbdev.wataru.com/wataru/fe-site-ka-testing
  # 演示版：正式环境、预发环境、测试环境
  #   正式：harbor.wataru.com/wataru/fe-site-demo:1.1.1-demo
  #   测试：hbdev.wataru.com/wataru/fe-site-mock:testing
  DOCKER_IMAGE_NAME: wataru/fe-site # 通用的 docker 镜像名称地址
  STAGING_DOCKER_IMAGE_NAME: wataru/fe-site # 标准版预发环境 docker 镜像名称地址，"hbdev.wataru.com/wataru/fe-site"除去域名的剩下部分
  TESTING_DOCKER_IMAGE_NAME: wataru/fe/fe-site # 标准版测试环境 docker 镜像名称地址
  MOCK_DOCKER_IMAGE_NAME: wataru/fe-site-mock # 演示版测试环境 docker 镜像名称地址
  DEMO_DOCKER_IMAGE_NAME: wataru/fe-site-demo # 演示版正式环境 docker 镜像名称地址
  KA_DOCKER_IMAGE_NAME: wataru/fe-site-staging # 私有化交付 docker 镜像名称
  KA_DOCKER_IMAGE_NAME_TESTING: wataru/fe/fe-site-ka-testing # 私有化测试 docker 镜像名称

  # 在kubernetes中的命名空间namespace可以用来批量部署镜像，如果想有规划地部署，可以创建多个分类的namespace命名空间，在不同namespace部署不同的分类，比如预发环境（所有项目）/测试环境（所有项目），或者某个项目（包括xx环境/xx环境等）。
  # 在kubernetes中有多个命名空间namespace，namespace可以当做是某个xx环境,比如测试/预发/正式等。同一个环境的前后端的镜像，放在同一个namespace中。
  # 我的namespace命名空间是wataru，我用来做预发环境，deployment就是我要部署的镜像项目名称
  # namespace: wataru
  #   deployment: fe-site (网站),fe-mobile(移动端) 等，deployment下的名称是自己定义的，叫啥都行

  STAGING_K8S_NAMESPACE: wataru # 标准版预发环境命名空间，可在drone.yml中的 - kubectl apply -f ./k8s/ka-testing.yaml -n wataru，查看
  TESTING_K8S_NAMESPACE: wataru # 标准版测试环境命名空间，
  KA_TESTING_K8S_NAMESPACE: ka-testing # 私有化版-测试环境 K8S 命名空间，可在drone.yml中的 - kubectl apply -f ./k8s/ka-testing.yaml -n ka-testing，查看
  KA_STAGING_K8S_NAMESPACE: wataru-stable # 私有化版-预发环境 K8S 命名空间，可在drone.yml中的 - kubectl apply -f ./k8s/ka-staging.yaml -n wataru-stable 查看

  MOCK_TESTING_DEPLOYMENT_NAME: fe-site-mock # 演示版-测试环境-deployment的名称，跟deployment里要对上，要么yaml里用占位符,在drone.yml中的 - kubectl rollout restart deployment fe-site-mock -n wataru 查看 “deployment”后的“fe-site-mock”就是 deployment_name
  TESTING_DEPLOYMENT_NAME: fe-site # 标准版-测试环境-deployment的名称，跟kubernetes的namespace命名空间下的deployment里的名称要对上，要么yaml里用占位符
  STAGING_DEPLOYMENT_NAME: fe-site # 标准版-测试环境-deployment的名称，跟kubernetes的namespace命名空间下的deployment里的名称要对上，要么yaml里用占位符
  KA_TESTING_DEPLOYMENT_NAME: fe-site # 私有化版-测试环境-deployment名称， 跟kubernetes的namespace命名空间下的deployment里的名称要对上，要么yaml里用占位符
  KA_STAGING_DEPLOYMENT_NAME: fe-site # 私有化版-预发环境-deployment名称，跟kubernetes的namespace命名空间下的deployment里的名称要对上，要么yaml里用占位符

  # 打docker镜像的Dockerfile配置文件
  PRODUCTION_DOCKERFILE: Dockerfile # 正式环境打docker镜像的Dockerfile文件
  STAGING_DOCKERFILE: Dockerfile.rel # 预发/测试（开发过程不断更新镜像时用这个）环境打docker镜像的Dockerfile文件，这里没用上
  TESTING_DOCKERFILE: Dockerfile.testing # 测试环境打docker镜像的Dockerfile文件
  KA_TESTING_DOCKERFILE: Dockerfile.testing # 私有化版-测试环境-dockerfile打包文件
  KA_PRODUCTION_DOCKERFILE: Dockerfile # 私有化版-预发/正式环境-dockerfile打包文件

  STATIC_PUBLIC_PATH: /wataru/1.0 # 静态资源上传的地址oss

# 下面一般不需要动

stages:
  - check
  - build
  - deploy
  - test

# ========================= check =========================
opensca-check:
  stage: check
  tags:
    - "check"
  image: hbdev.wataru.com/dev/opensca:1.0.9
  script:
    - /usr/local/bin/opensca-scan.sh
  only:
    - merge_requests
    - master
    # - develop
    # - /^testing\/*/
    - /^staging.*/
    - /^feature\/*/
    - /^hotfix\/*/
sonarqube-check:
  stage: check
  tags:
    - "check"
  image: sonarsource/sonar-scanner-cli:4.6
  allow_failure: true # 能强制的时候把这个干掉
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
    GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task
  cache:
    key: "SONAR_${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script:
    # 暂时不强求
    - |
      if [ -f "sonar-project.properties" ];then
      sonar-scanner -Dsonar.sources=. -Dsonar.branch.name=$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
      fi
  only:
    - merge_requests
    - master
    - /^staging*/

# ========================= build =========================
docker-build:
  # Use the official docker image.
  image:
    name: docker:20.10.17
    #pull_policy: if-not-present
  stage: build
  tags:
    - "frontend" # golang: go后端项目,frontend：前端项目，php: PHP项目
  services:
    - docker:20.10.17-dind
  cache:
    key: "BUILD_DOCKER_${CI_JOB_NAME}"
    paths:
      - .docker/cache
  before_script:
    # HARBOR_REGISTRY：harbor仓库地址，HARBOR_USERNAME：harbor仓库用户名，HARBOR_PASSWORD：harbor仓库登录密码
    # PRODUCTION_HARBOR_REGISTRY
    # PRODUCTION_HARBOR_USERNAME
    # PRODUCTION_HARBOR_PASSWORD

    # TESTING_HARBOR_REGISTRY
    # TESTING_HARBOR_USERNAME
    # TESTING_HARBOR_PASSWORD

    # KA_TESTING_HARBOR_REGISTRY
    # KA_TESTING_HARBOR_USERNAME
    # KA_TESTING_HARBOR_PASSWORD

    # KA_HARBOR_REGISTRY
    # KA_HARBOR_USERNAME
    # KA_HARBOR_PASSWORD

    # CI_COMMIT_BRANCH：提交的分支
    - |
      HARBOR_REGISTRY=$PRODUCTION_HARBOR_REGISTRY
      HARBOR_USERNAME=$PRODUCTION_HARBOR_USERNAME
      HARBOR_PASSWORD=$PRODUCTION_HARBOR_PASSWORD
      if [[ "$CI_COMMIT_BRANCH" =~ ^testing* ]]; then
        echo "image will publish to testing repository!"
        HARBOR_REGISTRY=$TESTING_HARBOR_REGISTRY
        HARBOR_USERNAME=$TESTING_HARBOR_USERNAME
        HARBOR_PASSWORD=$TESTING_HARBOR_PASSWORD
      elif [[ "$CI_COMMIT_BRANCH" =~ ^ka-testing* ]]; then
        echo "image will publish to ka-testing repository!"
        HARBOR_REGISTRY=$KA_TESTING_HARBOR_REGISTRY
        HARBOR_USERNAME=$KA_TESTING_HARBOR_USERNAME
        HARBOR_PASSWORD=$KA_TESTING_HARBOR_PASSWORD
      elif [[ "$CI_COMMIT_BRANCH" =~ ^ka-staging* ]]; then
        echo "image will publish to ka-staging repository!"
        HARBOR_REGISTRY=$KA_HARBOR_REGISTRY
        HARBOR_USERNAME=$KA_HARBOR_USERNAME
        HARBOR_PASSWORD=$KA_HARBOR_PASSWORD
      fi
    - docker login -u "$HARBOR_USERNAME" -p "$HARBOR_PASSWORD" $HARBOR_REGISTRY
  script:
    # CI_COMMIT_REF_SLUG：当前分支或者tag，格式是：v1-1-1-ka
    # CI_COMMIT_TAG：打的tag名称，格式是：v1.1.1-ka
    # tagName=${CI_COMMIT_REF_SLUG//-/.}，表示用 . 替换掉 - ，v1-1-1-ka变成 v1.1.1.ka
    # 使用tagName=${CI_COMMIT_TAG},，然后把v干掉
    # tag=":${tagName//v/}"，表示空字符替换v，也就是把v删掉
    - |
      DOCKERFILE_NAME=$PRODUCTION_DOCKERFILE
      if [[ "$CI_COMMIT_BRANCH" =~ ^st-testing* ]]; then
        tag=":testing" # 标准测试：hbdev.wataru.com/wataru/fe-site:testing，tag是fe-site:testing的“:testing”
        DOCKERFILE_NAME=$TESTING_DOCKERFILE
      elif [[ "$CI_COMMIT_BRANCH" =~ ^staging* ]]; then
        tag=":staging" # 标准预发：hbdev.wataru.com/wataru/fe-site:staging，tag是fe-site:staging的“:staging”
        DOCKER_IMAGE_NAME=$STAGING_DOCKER_IMAGE_NAME
      elif [[ "$CI_COMMIT_BRANCH" =~ ^ka-testing$ ]]; then # 分支名 ^X：以X开头，X$:以X结束，^ka-testing$，以ka-testing开头和结束，即精确匹配ka-testing
        tag="" # 私有化测试：hbdev.wataru.com/wataru/fe-site-ka-testing，没有“:xxx”，tag是""，默认是latest
        DOCKER_IMAGE_NAME=$KA_DOCKER_IMAGE_NAME_TESTING
      elif [[ "$CI_COMMIT_BRANCH" =~ ^st-mock$ ]]; then
        tag=""
        DOCKER_IMAGE_NAME=$MOCK_DOCKER_IMAGE_NAME
      elif [[ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]]; then
        tag=""
        echo "Running on default branch '$CI_DEFAULT_BRANCH': tag = 'latest'" # 打印出CI_DEFAULT_BRANCH
      else
        # 你在gitlab上打的tag标签是v1.1.1-ka
        # tagName=${CI_COMMIT_REF_SLUG//-/.}，CI_COMMIT_REF_SLUG：当前分支或者tag标签，格式是：v1-1-1-ka
        tagName=${CI_COMMIT_TAG} # CI_COMMIT_TAG的格式是：v1.1.1-ka
        tag=":${tagName//v/}" # tag=":${tagName//v/}"，表示空字符替换v，也就是把v删掉
        if [[ "$CI_COMMIT_TAG" =~ .*-demo$ ]]; then
          DOCKER_IMAGE_NAME=$DEMO_DOCKER_IMAGE_NAME
        fi
        echo "Running on branch '$CI_COMMIT_BRANCH': tag = $tag"
      fi
      echo "prepared to build docker image: ${HARBOR_REGISTRY}/${DOCKER_IMAGE_NAME}${tag}"
    - docker build . -t "${HARBOR_REGISTRY}/${DOCKER_IMAGE_NAME}${tag}" -f $DOCKERFILE_NAME --build-arg OSS_ACCESS_KEY="${STATIC_OSS_ACCESS_KEY}" --build-arg OSS_ACCESS_SECRET="${STATIC_OSS_ACCESS_SECRET}"  --build-arg OSS_ENDPOINT="${STATIC_OSS_ENDPOINT}"
    - docker push "${HARBOR_REGISTRY}/${DOCKER_IMAGE_NAME}${tag}"
  # Run this job in a branch where a Dockerfile exists
  only:
    - tags
    #- master
    - /^st-testing.*/
    - /^testing.*/
    - /^staging.*/
    - /^ka-staging.*/
    - /^ka-testing.*/
    - /^ka-testing$/
    - /^st-mock$/

# ========================= deploy =========================
deploy-k8s:
  stage: deploy
  tags:
    - "public"
  image: meltwaterfoundation/drone-kubectl:1.18
  script:
    # drone.yml - kubectl apply -f ./k8s/st-mock.yaml -n wataru
    # 对应这里的 - kubectl apply -f ./k8s/${conf}.yaml -n $ns 

    # TESTING_K8S_SERVER、TESTING_K8S_TOKEN 等 x_K8S_TOKEN、x_K8S_SERVER 是在gitlab配置的常量，这些常量是 kubernetes 上的服务器地址和登录token
    # 目前已知的有：
    # TESTING_K8S_SERVER
    # TESTING_K8S_TOKEN

    # STAGING_K8S_SERVER
    # STAGING_K8S_TOKEN

    # KA_TESTING_K8S_SERVER
    # KA_TESTING_K8S_TOKEN
    - |
      if [[ "$CI_COMMIT_BRANCH" =~ ^st-testing* ]]; then
        conf="st-testing"
        ns=$TESTING_K8S_NAMESPACE
        svr=$TESTING_K8S_SERVER
        token=$TESTING_K8S_TOKEN
        deployment=$TESTING_DEPLOYMENT_NAME
      elif [[ "$CI_COMMIT_BRANCH" =~ ^staging* ]]; then
        conf="staging"
        ns=$STAGING_K8S_NAMESPACE
        svr=$STAGING_K8S_SERVER
        token=$STAGING_K8S_TOKEN
        deployment=$STAGING_DEPLOYMENT_NAME
      elif [[ "$CI_COMMIT_BRANCH" =~ ^ka-staging* ]]; then
        conf="ka-staging"
        ns=$KA_STAGING_K8S_NAMESPACE
        svr=$KA_STAGING_K8S_SERVER
        token=$KA_STAGING_K8S_TOKEN
        deployment=$KA_STAGING_DEPLOYMENT_NAME
      elif [[ "$CI_COMMIT_BRANCH" =~ ^ka-testing* ]]; then
        conf="ka-testing"
        ns=$KA_TESTING_K8S_NAMESPACE
        svr=$KA_TESTING_K8S_SERVER
        token=$KA_TESTING_K8S_TOKEN
        deployment=$KA_TESTING_DEPLOYMENT_NAME
      elif [[ "$CI_COMMIT_BRANCH" =~ ^st-mock* ]]; then
        conf="st-mock"
        ns=$TESTING_K8S_NAMESPACE
        svr=$TESTING_K8S_SERVER
        token=$TESTING_K8S_TOKEN
        deployment=$MOCK_TESTING_DEPLOYMENT_NAME
      else
        echo "not a valid branch deploy by gitlab-ci"
        exit -1
      fi
      echo "enter deploy  $deployment  -n $ns"
      kubectl config set-cluster kubernetes --insecure-skip-tls-verify=true --server=$svr
      kubectl config set-credentials admin --token=$token
      kubectl config set-context deploy --cluster=kubernetes --user=admin
      kubectl config use-context deploy
      kubectl apply -f ./k8s/${conf}.yaml -n $ns # 只有这里用的配置文件不一样
      kubectl rollout restart deployment $deployment -n $ns
  only:
    - /^st-testing.*/
    - /^staging.*/
    - /^testing.*/
    - /^ka-staging.*/
    - /^ka-testing.*/
    - /^ka-testing$/
    - /^st-mock$/

# ========================= test =========================
# sql注入扫描
# sqlmap:
#   stage: test
#   tags:
#     - "testing"
#     - "security"
#   image:
#     name: "googlesky/sqlmap:latest"
#     #pull_policy: if-not-present
#   before_script:
#     - ｜
#        # 如果服务需要授权，想办法给sqlmap一个时间足够长的token
#   script:
#     - sqlmap -r tests/sqlmap/
#   only:
#     - /^testing*/  # sqlmap只能在测试环境执行

# http接口测试
# httptest:
#   stage: test
#   tags:
#     - "testing"
#   image:
#     name: "hbdev.wataru.com/dev/apifox-cli:latest"
#     #pull_policy: if-not-present
#   before_script:
#     - ｜
#        # 如果服务需要授权...
#   script:
#     - apifox-cli -f
#   only:
#     - /^testing*/

GitLab CI/CD的预置变量

VariableGitLabRunnerDescription
CHAT_CHANNEL10.6all触发ChatOps命令的源聊天通道
CHAT_INPUT10.6all在ChatOps命令中传递的其他参数
CIall0.4标记作业在 CI 环境中执行
CI_API_V4_URL11.7allGitLab API v4 根 URL
CI_BUILDS_DIRall11.10执行构建的顶级目录.
CI_COMMIT_BEFORE_SHA11.2all先前的最新提交存在于分支中. 合并请求的管道中始终为0000000000000000000000000000000000000000
CI_COMMIT_DESCRIPTION10.8all提交的描述：如果标题少于 100 个字符，则不带第一行的消息； 在其他情况下为完整消息.
CI_COMMIT_MESSAGE10.8all完整的提交消息.
CI_COMMIT_REF_NAME9.0all构建项目的分支或标记名称
CI_COMMIT_REF_PROTECTED11.11all如果作业在受保护的引用上运行，则为true否则为false
CI_COMMIT_REF_SLUG9.0all$CI_COMMIT_REF_NAME小写，缩短为 63 个字节，并且将0-9和az以外的所有内容替换为- . 没有前导/尾随- . 在 URL，主机名和域名中使用.
CI_COMMIT_SHA9.0all为其构建项目的提交修订
CI_COMMIT_SHORT_SHA11.7allCI_COMMIT_SHA的前八个字符
CI_COMMIT_BRANCH12.60.5提交分支名称. 仅在建立分支时显示.
CI_COMMIT_TAG9.00.5提交标记名称. 仅在构建标签时显示.
CI_COMMIT_TITLE10.8all提交的标题-消息的第一行
CI_CONCURRENT_IDall11.10单个执行程序中生成执行的唯一 ID.
CI_CONCURRENT_PROJECT_IDall11.10单个执行程序和项目中生成执行的唯一 ID.
CI_CONFIG_PATH9.40.5CI 配置文件的路径. 默认为.gitlab-ci.yml
CI_DEBUG_TRACEall1.7是否启用调试日志记录（跟踪）
CI_DEFAULT_BRANCH12.4all项目的默认分支的名称.
CI_DEPLOY_PASSWORD10.8allGitLab Deploy 令牌的身份验证密码，仅在项目具有相关性时才提供.
CI_DEPLOY_USER10.8allGitLab Deploy 令牌的身份验证用户名，仅在项目具有相关性时才存在.
CI_DISPOSABLE_ENVIRONMENTall10.1标记作业是在一次性环境中执行的（仅为该作业创建并在执行后处置/销毁的东西-除shell和ssh以外的所有执行程序）. 如果环境是一次性的，则将其设置为 true，否则将完全未定义.
CI_ENVIRONMENT_NAME8.15all该作业的环境名称. 仅在设置了environment:name存在.
CI_ENVIRONMENT_SLUG8.15all环境名称的简化版本，适合包含在 DNS，URL，Kubernetes 标签等中.仅在设置了environment:name存在.
CI_ENVIRONMENT_URL9.3all该作业的环境的 URL. 仅当设置了environment:url时才存在.
CI_EXTERNAL_PULL_REQUEST_IID12.3all如果管道用于外部请求，则来自 GitHub 的请求请求 ID. 仅在以下情况only: [external_pull_requests]可用only: [external_pull_requests]或rules语法，并且拉取请求处于打开状态.
CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_NAME12.3all如果管道用于外部请求，则请求请求的源分支名称. 仅在以下情况only: [external_pull_requests]可用only: [external_pull_requests]或rules语法，并且拉取请求处于打开状态.
CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_SHA12.3all如果管道用于外部请求，则请求请求的源分支的 HEAD SHA. 仅在以下情况only: [external_pull_requests]可用only: [external_pull_requests]或rules语法，并且拉取请求处于打开状态.
CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_NAME12.3all如果管道用于外部请求，则请求请求的目标分支名称. 仅在以下情况only: [external_pull_requests]可用only: [external_pull_requests]或rules语法，并且拉取请求处于打开状态.
CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_SHA12.3all如果管道用于外部请求，则请求请求目标分支的 HEAD SHA. 仅在以下情况only: [external_pull_requests]可用only: [external_pull_requests]或rules语法，并且拉取请求处于打开状态.
CI_HAS_OPEN_REQUIREMENTS13.1all仅当管道的项目有任何开放要求时，才将值包括为true . 如果管道项目没有开放要求，则不包括在内.
CI_JOB_ID9.0allGitLab CI / CD 在内部使用的当前作业的唯一 ID
CI_JOB_IMAGE12.912.9运行 CI 作业的图像的名称
CI_JOB_MANUAL8.12all指示作业已手动启动的标志
CI_JOB_NAME9.00.5.gitlab-ci.yml定义的作业名称
CI_JOB_STAGE9.00.5.gitlab-ci.yml定义的阶段名称
CI_JOB_TOKEN9.01.2用于通过GitLab 容器注册表进行身份验证，下载从属存储库以及访问GitLab 管理的 Terraform 状态的令牌.
CI_JOB_JWT12.10allRS256 JSON Web 令牌，可用于与支持 JWT 身份验证的第三方系统进行身份验证，例如HashiCorp 的 Vault .
CI_JOB_URL11.10.5职位详情网址
CI_KUBERNETES_ACTIVE13.0allIncluded with the value true only if the pipeline has a Kubernetes cluster available for deployments. Not included if no cluster is available. Can be used as an alternative to only:kubernetes/except:kubernetes with rules:if
CI_MERGE_REQUEST_ASSIGNEES11.9all如果管道用于合并请求 ，则该合并请求的受让人的用户名列表用逗号分隔. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法并创建合并请求.
CI_MERGE_REQUEST_ID11.6all合并请求的项目级别 ID. 仅当管道用于合并请求并且创建合并请求时才可用.
CI_MERGE_REQUEST_IID11.6all合并请求的实例级 IID. 仅当管道用于合并请求并且创建合并请求时才可用.
CI_MERGE_REQUEST_LABELS11.9all如果管道用于合并请求 ，则合并请求的逗号分隔标签名称. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法并创建合并请求.
CI_MERGE_REQUEST_MILESTONE11.9all如果管道用于合并请求 ，则合并请求的里程碑标题. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法并创建合并请求.
CI_MERGE_REQUEST_PROJECT_ID11.6all如果管道用于合并请求 ，则合并请求的项目的 ID. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法并创建合并请求.
CI_MERGE_REQUEST_PROJECT_PATH11.6all如果管道用于合并请求 ，则合并请求的项目路径（例如， namespace/awesome-project ）. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法并创建合并请求.
CI_MERGE_REQUEST_PROJECT_URL11.6all如果管道用于合并请求 ，则合并请求的项目的 URL（例如http://192.168.10.15:3000/namespace/awesome-project ）. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法并创建合并请求.
CI_MERGE_REQUEST_REF_PATH11.6all如果管道用于合并请求 ，则合并请求的 ref 路径. （例如refs/merge-requests/1/head ）. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法并创建合并请求.
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME11.6all如果管道用于合并请求 ，则合并请求的源分支名称. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法并创建合并请求.
CI_MERGE_REQUEST_SOURCE_BRANCH_SHA11.9all如果管道用于合并请求 ，则合并请求的源分支的 HEAD SHA. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法，创建合并请求，并且管道是合并结果管道 .
CI_MERGE_REQUEST_SOURCE_PROJECT_ID11.6all如果管道用于合并请求 ，则合并请求的源项目的 ID. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法并创建合并请求.
CI_MERGE_REQUEST_SOURCE_PROJECT_PATH11.6all如果管道用于合并请求 ，则合并请求的源项目的路径. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法并创建合并请求.
CI_MERGE_REQUEST_SOURCE_PROJECT_URL11.6all如果管道用于合并请求 ，则合并请求的源项目的 URL. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法并创建合并请求.
CI_MERGE_REQUEST_TARGET_BRANCH_NAME11.6all如果管道用于合并请求 ，则合并请求的目标分支名称. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法并创建合并请求.
CI_MERGE_REQUEST_TARGET_BRANCH_SHA11.9all如果管道用于合并请求 ，则合并请求的目标分支的 HEAD SHA. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法，创建合并请求，并且管道是合并结果管道 .
CI_MERGE_REQUEST_TITLE11.9all如果管道用于合并请求 ，则合并请求的标题. 仅在以下情况only: [merge_requests]可用：仅使用only: [merge_requests]或rules语法并创建合并请求.
CI_MERGE_REQUEST_EVENT_TYPE12.3all合并请求的事件类型（如果管道用于合并请求） . 可以detached ， merged_result或merge_train .
CI_NODE_INDEX11.5all作业在作业集中的索引. 如果作业未并行化，则不会设置此变量.
CI_NODE_TOTAL11.5allTotal number of instances of this job running in parallel. If the job is not parallelized, this variable is set to 1.
CI_PAGES_DOMAIN11.8all托管 GitLab 页面的已配置域.
CI_PAGES_URL11.8allGitLab 页面构建页面的 URL. 始终属于CI_PAGES_DOMAIN的子域.
CI_PIPELINE_ID8.10allGitLab CI / CD 在内部使用的当前管道的唯一 ID
CI_PIPELINE_IID11.0all当前管道的唯一 ID 范围为项目
CI_PIPELINE_SOURCE10.0all指示如何触发管道. 可能的选项是： push ， web ， schedule ， api ， external ， chat ， webide ， merge_request_event ， external_pull_request_event ， parent_pipeline ， trigger或pipeline （自 13.0 起改名为cross_project_pipeline ）. 对于在 GitLab 9.5 之前创建的管道，这将显示为unknown .
CI_PIPELINE_TRIGGEREDallall指示已触发作业的标志
CI_PIPELINE_URL11.10.5管道详细资料网址
CI_PROJECT_DIRallall克隆存储库以及运行作业的完整路径. 如果设置了 GitLab Runner 的builds_dir参数，则相对于builds_dir的值设置此变量. 有关更多信息，请参见 GitLab Runner 的高级配置 .
CI_PROJECT_IDallallGitLab CI / CD 在内部使用的当前项目的唯一 ID
CI_PROJECT_NAME8.100.5当前正在构建的项目的目录名称. 例如，如果项目 URL 为gitlab.example.com/group-name/project-1 ，则CI_PROJECT_NAME将为project-1 .
CI_PROJECT_NAMESPACE8.100.5当前正在构建的项目名称空间（用户名或组名）
CI_PROJECT_ROOT_NAMESPACE13.20.5当前正在构建的根项目名称空间（用户名或组名）. 例如，如果CI_PROJECT_NAME是root-group/child-group/grandchild-group ，则CI_PROJECT_ROOT_NAMESPACE将是root-group .
CI_PROJECT_PATH8.100.5具有项目名称的名称空间
CI_PROJECT_PATH_SLUG9.3all$CI_PROJECT_PATH小写，除0-9和az以外的所有内容都用-代替. 在 URL 和域名中使用.
CI_PROJECT_REPOSITORY_LANGUAGES12.3all库中使用的语言的逗号分隔，小写列表（例如ruby,javascript,html,css ）
CI_PROJECT_TITLE12.4all可读的项目名称，显示在 GitLab Web 界面中.
CI_PROJECT_URL8.100.5The HTTP(S) address to access project
CI_PROJECT_VISIBILITY10.3all项目可见性（内部，私人，公共）
CI_REGISTRY8.100.5如果启用了 Container Registry，它将返回 GitLab 的 Container Registry 的地址. 如果在注册表配置中指定了一个变量，则该变量将包含:port值.
CI_REGISTRY_IMAGE8.100.5如果为项目启用了容器注册表，则它将返回绑定到特定项目的注册表地址
CI_REGISTRY_PASSWORD9.0allThe password to use to push containers to the GitLab Container Registry, for the current project.
CI_REGISTRY_USER9.0all用于将容器推送到当前项目的 GitLab 容器注册表的用户名.
CI_REPOSITORY_URL9.0all克隆 Git 存储库的 URL
CI_RUNNER_DESCRIPTION8.100.5保存在 GitLab 中的跑步者的描述
CI_RUNNER_EXECUTABLE_ARCHall10.6GitLab Runner 可执行文件的操作系统/体系结构（请注意，它不一定与执行程序的环境相同）
CI_RUNNER_ID8.100.5正在使用的跑步者的唯一 ID
CI_RUNNER_REVISIONall10.6正在执行当前作业的 GitLab Runner 版本
CI_RUNNER_SHORT_TOKENall12.3GitLab Runner 令牌的前八个字符用于验证新的作业请求. 用作跑步者的唯一 ID
CI_RUNNER_TAGS8.100.5定义的运行器标签
CI_RUNNER_VERSIONall10.6正在执行当前作业的 GitLab Runner 版本
CI_SERVERallall标记作业在CI 环境中执行
CI_SERVER_URL12.7allGitLab 实例的基本 URL，包括协议和端口（例如https://gitlab.example.com:8080 ）
CI_SERVER_HOST12.1allGitLab 实例 URL 的主机组件，不带协议和端口（例如gitlab.example.com ）
CI_SERVER_PORT12.8allGitLab 实例 URL 的端口组件，不包含主机和协议（例如3000 ）
CI_SERVER_PROTOCOL12.8allGitLab 实例 URL 的协议组件，不带主机和端口（例如https ）
CI_SERVER_NAMEallall用于协调作业的 CI 服务器的名称
CI_SERVER_REVISIONallall用于计划作业的GitLab 修订版
CI_SERVER_VERSIONallall用于计划作业的 GitLab 版本
CI_SERVER_VERSION_MAJOR11.4allGitLab 版本主要组件
CI_SERVER_VERSION_MINOR11.4allGitLab 版本次要组件
CI_SERVER_VERSION_PATCH11.4allGitLab 版本补丁组件
CI_SHARED_ENVIRONMENTall10.1标记作业是在共享环境中执行的（在诸如shell或ssh执行程序之类的 CI 调用之间持久存在的内容）. 如果共享环境，则将其设置为 true，否则将完全未定义.
GITLAB_CIallall标记作业在 GitLab CI / CD 环境中执行
GITLAB_FEATURES10.6all以逗号分隔的实例和计划可用的许可功能列表
GITLAB_USER_EMAIL8.12all开始工作的用户的电子邮件
GITLAB_USER_ID8.12all开始工作的用户的 ID
GITLAB_USER_LOGIN10.0all开始工作的用户的登录用户名
GITLAB_USER_NAME10.0all开始工作的用户的真实姓名

扩展阅读：

《GitLab CI/CD 流水线配置 pipeline configuration reference》：https://gitlab.apachecn.org/#/docs/199
《GitLab CI/CD》：https://gitlab.apachecn.org/#/docs/198
《GitLab CI/CD预置变量》：https://gitlab.apachecn.org/#/docs/221
《GitLab CI/CD》英文原文文档：https://docs.gitlab.com/ee/ci/variables/index.html#for-an-instance

 类似资料：

相关阅读

在Jenkins中配置GitLab存储库如何使用Gitlab CI构建，推送和拉取多个Docker容器？GitLab CI运行程序无法连接到Kubernetes中的unix：///var/run/docker.sockGitlab CI运行程序无法公开嵌套Docker容器的端口CI配置多数据库访问的方法

相关文章

GitLab简介GitLab教程GitLab SSH密钥设置GitLab里程碑GitLab创建组

相关问答

Gitlab CI儿童管道gitlab ci中配置了rules为什么不生效？Gitlab CI阶段和依赖Gitlab-CI和Maven-元数据此GitLab CI配置无效：根配置包含未知的键：标记

相关文档

GitBook 安装配置使用Mac 开发配置手册ZUK Z2 (z2_plus) 设备配置配色宝典配色手册
快捷导航： 新手教程 算法原理 架构设计 Java进阶 数据库进阶 大厂专栏 面试经验 编程笔记 编程问答 所有专题 文档资料 工具软件 电子书籍 小牛导航
在线工具： 房贷计算器 个税计算器 Linux命令查询 Json格式化 正则表达式 颜色转换 AES加解密 SHA1加密 MD5加密 毒鸡汤 字数统计 随机密码生成 进制转换 Base64编解码 励志句子
Copyright © 2019-2024 小牛知识库@xnip.cn. All Rights Reserved.