1. 授权认证
  2. 获取用户个人信息
  3. 项目协同
  4. 代码托管
  5. 持续集成
  6. 制品仓库
  7. 测试管理
  8. 文档管理
  1. 项目协同
  2. 代码仓库
  3. DevOps 实践之旅
  4. 一分钟开始持续集成之旅
  5. 持续部署
  6. 制品库

持续集成的环境变量

功能介绍

持续集成过程中,我们总会将一些配置(如:账号密码/版本号等)信息以环境变量的形式注入到构建过程中。CODING 持续集成支持多种环境变量使用形式,您可以同时使用以下几种方式来为构建过程注入环境变量,其优先级为从上到下(排在前面的配置优先级最高):

  • Jenkinsfile 中的 withEnv
  • Jenkinsfile 中的 environment
  • 构建计划(Job)中的启动参数
  • 构建计划(Job)设置中的环境变量
  • 构建过程中系统内置的环境变量

下文将详细介绍这几种方式的详细说明。

Jenkinsfile 中的 withEnv 和 environment

您可以在 Jenkinsfile 中使用 environment 来定义环境变量(如下所示):

pipeline {
    agent any
    environment {
        MY_PROJECT = 'project-1'
        MY_TEAM    = 'team-1'
    }
    stages {
        stage('Build') {
            steps {

                echo "MY_PROJECT is ${MY_PROJECT}"
                echo "MY_TEAM is ${MY_TEAM}"
                // 输出内容如下所示:
                // MY_PROJECT is project-1
                // MY_TEAM is team-1
            }
        }
    }
}

在构建过程中,可能需要在不同的阶段使用同名的环境变量。可以使用 withEnv 来针对部分操作设置环境变量,避免全局的环境变量污染。 withEnv 中所执行的 step ,都将优先使用 withEnv 设置的环境变量。具体效果可以参考以下例子:

pipeline {
    agent any
    environment {
        MY_PROJECT = 'project-1'
        MY_TEAM    = 'team-1'
    }
    stages {
        stage('Build') {
            steps {

                echo "MY_PROJECT is ${MY_PROJECT}"
                echo "MY_TEAM is ${MY_TEAM}"
                // 输出内容如下所示:
                // MY_PROJECT is project-1
                // MY_TEAM is team-1

                // withEnv 中设置的环境变量只对作用域下的 step 有效,优先级高于 environment 
                withEnv(['MY_PROJECT=project-2']) {

                    echo "MY_PROJECT is ${MY_PROJECT}"
                    echo "MY_TEAM is ${MY_TEAM}"                    
                    // 输出内容如下所示:
                    // MY_PROJECT is project-2
                    // MY_TEAM is team-1

                }
            }
        }
    }
}

如果您想了解更多 Jenkinsfile 环境变量相关内容,可以拓展阅读:《Jenkins 官方文档——使用环境变量》

构建计划中的启动参数

优先级仅次于 Jenkinsfile 中配置的环境变量,您可以在启动构建计划时,选择或填写对应的环境变量值。

构建计划设置中的环境变量

除了在 Jenkinsfile 中硬编码环境变量,还可以在构建计划的配置中进行设置。目前 CODING 支持添加以下四种类别的环境变量:字符串、单选、多选、Coding 凭据。您还可以将构建计划中的环境变量配置视为启动参数的默认值。

构建过程中系统内置的环境变量

CODING 持续集成在构建过程中,会为每一个构建任务注入对应的环境变量,默认注入的环境变量列表您可以在构建快照中查看:

所有环境变量汇总如下,按照不同的触发规则(代码更新时触发、定时触发、合并请求时触发)进行分类介绍:

序号 变量名 变量含义 代码更新时触发 定时触发 合并请求时触发
1 CREDENTIALS_ID 部署私钥凭据 CredentialsId 用于拉取仓库
2 DOCKER_REGISTRY_CREDENTIALS_ID docker 私钥凭据 CredentialsId(等同于 CODING_ARTIFACTS_CREDENTIALS_ID)
3 CODING_ARTIFACTS_CREDENTIALS_ID 制品库私钥凭据 CredentialsId 用于拉取项目内的制品库
4 GIT_HTTP_URL HTTPS 协议代码仓库地址
5 GIT_BUILD_REF 构建对应的 Git 修订版本号
6 GIT_DEPLOY_KEY 代码仓库的部署公钥
7 GIT_COMMIT 当前版本的修订版本号
7 GIT_COMMIT_SHORT 修订版本号的前 7 位
8 GIT_PREVIOUS_COMMIT 前一个构建运行编号的修订版本号
9 GIT_AUTHOR_EMAIL 本版本最新提交作者邮箱
10 GIT_SSH_URL 协议代码仓库地址
11 GIT_COMMITTER_NAME 本版本最新提交者名称
12 GIT_AUTHOR_NAME 本版本最新提交作者名称
13 REF 要构建的版本
14 GIT_PREVIOUS_SUCCESSFUL_COMMIT 前一个构建运行成功的修订版本号
15 GIT_COMMITTER_EMAIL 本版本最新提交者名称
16 GIT_BRANCH 触发构建的分支
17 GIT_URL 仓库 SSH 协议地址
18 GIT_LOCAL_BRANCH/BRANCH_NAME 本地分支名称
19 FETCH_REF_SPECS git 要检出的 refs
20 GIT_REPO_URL 仓库 SSH 地址
21 JOB_ID 构建计划 id
22 JOB_NAME 构建计划名称
23 CI_BUILD_NUMBER 构建编号
24 PROJECT_ID 项目 ID
25 PROJECT_NAME 项目名称
26 PROJECT_WEB_URL 项目网页地址
27 PROJECT_API_URL 项目后端 api 地址
28 PROJECT_TOKEN 项目令牌密码用于读取项目
29 PROJECT_TOKEN_GK 项目令牌用户名
30 GIT_TAG 触发构建的 Git 标签 (仅在使用标签构建的时候才会有)
31 DEPOT_NAME 当前使用的代码仓库名称
32 CCI_CURRENT_PROJECT_COMMON_CREDENTIALS_ID (即将上线) 内置项目令牌的 CredentialsId
33 CCI_CURRENT_TEAM (即将上线) 当前构建环境的企业名,如: myteam.coding.net 中的 myteam
34 CCI_CURRENT_DOMAIN (即将上线) 当前构建环境的域名,如: myteam.coding.net 中的 coding.net
35 MR_RESOURCE_ID 合并请求 ID
36 MR_TARGET_BRANCH 合并请求目标分支名
37 MR_TARGET_SHA 合并请求目标分支版本号
38 MR_MERGED_SHA 模拟合并完的版本号
39 MR_SOURCE_BRANCH 合并请求源分支名
40 MR_STATUS 合并请求状态
41 MR_SOURCE_SHA 合并请求源分支版本号

上一篇持续集成的构建环境
最近更新
感谢反馈有用
感谢反馈没用

在阅读中是否遇到以下问题?

您希望我们如何改进?