Devops-蓝鲸篇-04-蓝盾流水线详细介绍

Task 深入了解

Task,也被称为流水线插件,通常是一个单独的任务,如拉取 Git 仓库代码等。

Task 必须包含在 Job 内,同一个 Job 内的 Tasks 都是从上往下顺序执行(启用了高级流程控制的 Task 除外)。

自定义插件

通过研发商店,你可以开发自己的插件,目前已支持 Java/Python/NodeJS/Go 4 种主流语言

插件版本

每个插件都有版本控制,在使用插件时,你必须指定一个版本。

插件的版本规范:

  • 每次添加插件时,默认为当前插件的最新版本
  • 已添加的插件,版本号如果包含 N.latest,如果插件开发者发布了包含 N 的新特性版本,就会自动使用新版本

插件的通用选项

高级流程控制

通过高级流程控制,可以定义插件的运行逻辑。

插件输出

每个插件在运行之后,会产生一系列的输出变量,通过变量和高级流程控制的有效组合,可以实现各种应用场景。

输出字段命名空间: 用于解决流水线下,相同插件有多个实例时,输出字段使用冲突的问题。

  • 当没有冲突时,无需添加命名空间
  • 当修改了命名空间后,后续使用到对应字段的地方也需要同步修改

Jop 深入了解

Job,可以运行在一个构建环境里,比如运行在 macOS;也可以作为不需要构建环境的普通任务调度编排。它有如下特性:

  • 由多个 Tasks(插件)组成;
  • 一个 Task 失败,则该 Job 失败,其余 Task 将不会运行;

    BK-CI 内置了 Linux Docker 公共构建机(如果该选项无法选中,请联系您的 CI 平台管理员),同时也支持业务自己管理的 Windows、macOS、Linux 构建机。

WORKSPACE

每个 Job 都有自己的 WORKSPACE,WORKSPACE 就是该 Job 下所有插件的运行根目录。

由 BK-CI 自动生成的 WORKSPACE 中的文件不会随着 Docker 销毁而消失,只要是同一个流水线的同一个 Job,以下目录中的文件都是持久化存在的:

  • WORKSPACE:不指定的话就是当前 Job 的整个 WORKSPACE 目录
  • maven 缓存:/root/.m2/repository
  • npm 缓存:/root/Downloads/npm/prefix
  • npm 缓存:/root/Downloads/npm/cache
  • ccache 缓存:/root/.ccache
  • gradle 缓存:/root/.gradle/caches
  • golang 缓存:/root/go/pkg/mod
  • scale 缓存:/root/.ivy2
  • scale 缓存:/root/.cache
  • yarn 缓存:/usr/local/share/.cache/

如果一个 Job 中包含了"子流水线调用"插件,那该子流水线下的 Job 的 WORKSPACE 也会遵循上述原则,完全独立,不会跟父流水线的 WORKSPACE 冲突。

Job 的通用选项

流程控制选项

通过高级流程控制,可以定义 Job 的运行逻辑。

互斥组

互斥组是为了解决并发构建使用同一构建机时的资源冲突问题而设计的,对不同流水线的不同 Job 设置同一个互斥组。

Stage 深入了解

为了更清晰的描述 CI 流程,我们引入 Stage(阶段)的概念。

  • 由多个 Jobs(作业)组成;
  • 同一个 Stage 下的 Job 执行方式为并行,由于 Job 之间是相互独立的,某个 Job 失败后,其它的 Job 会被运行到完成;
  • 一个 Job 失败,则该 Stage 失败。

Stage准入

如果流水线需要中断流程,引入审核机制,那么Stage准入可以满足需求,它支持在流程中加入审批流。

如何使用

  • 点击Stage左侧的闪电ICON
  • 在弹出框里将准入规则改为"人工审核"(默认是自动,即不审核)
  • 设置对应的审批流(每个审批流可包含多个审批环节,如果一个审批环节中涉及多人时,任意一人审批即可进入下一审批环节)

高级玩法

  • 可通过设置"审批时间限制"来保护流水线任务,若超出时间仍未进行审批,视为审批不通过,流水线进入 STAGE_SUCCESS状态,流程终止。
  • 可通过设置"自定义参数"在审核时修改,用来改变流水线变量,再配合Job/Task的条件执行来影响后续流程。

Stage 的通用选项

Fastkill

开启 Fastkill 之后,当 Job 失败时立即结束当前 Stage。

流程控制选项

通过高级流程控制,可以定义 Job 的运行逻辑。

Variables

预定义常量/变量

合理的使用常量/变量可以更便捷的维护流水线,BK-CI 提供了很多系统常量/变量。

用法:插件配置中,输入 $ 即可获取对应变量的值。如 $

预定义常量

因历史原因,部分常量并未做覆盖限制,但不建议修改常量的值。

Variable Description 样例
BK_CI_PIPELINE_ID 流水线 ID,34 位长度,全局唯一 p-2fc5a05b25024d5586742b8e88d3c853
BK_CI_START_TYPE 构建启动方式,MANUAL/TIME_TRIGGER/WEB_HOOK/SERVICE/PIPELINE/REMOTE 中取值 WEB_HOOK
BK_CI_PROJECT_NAME 项目英文名 alltest
BK_CI_PIPELINE_NAME 流水线名称 持续交付流水线
BK_CI_BUILD_ID 流水线当前构建 ID,34 位长度,全局唯一 b-d82918fc4f5c44c790d538785685f36b
BK_CI_BUILD_NUM 构建序号,从 1 开始不断自增
BK_CI_BUILD_JOB_ID 流水线当前构建的当前 Job ID,34 位长度,全局唯一
BK_CI_BUILD_TASK_ID 流水线当前插件 Task ID,34 位长度,全局唯一
BK_CI_BUILD_REMARK 流水线构建备注信息,在流水线运行时通过 setEnv "BK_CI_BUILD_REMARK" 设置
BK_CI_BUILD_START_TIME 流水线启动时间, 毫秒数
BK_CI_BUILD_END_TIME 流水线结束时间, 毫秒数
BK_CI_BUILD_TOTAL_TIME 流水线执行耗时
BK_CI_BUILD_FAIL_TASKS 流水线执行失败的所有 TASK,内容格式:1、格式:[STAGE 别名][JOB 别名]TASK 别名 2、若有多个并发 JOB 失败,使用换行\n 分隔 可用于构建失败通知,或流水线执行过程中的插件中
BK_CI_BUILD_FAIL_TASKNAMES 流水线执行失败的所有 TASK,内容格式:TASK 别名,TASK 别名,TASK 别名 可用于构建失败通知,或流水线执行过程中的插件中
BK_CI_TURBO_ID 编译加速任务 ID,只有启用了编译加速才有该变量
BK_CI_MAJOR_VERSION 流水线里唯一,主版本号,开启"推荐版本号"功能后出现
BK_CI_MINOR_VERSION 流水线里唯一,特性版本,开启"推荐版本号"功能后出现
BK_CI_FIX_VERSION 流水线里唯一,修正版本,开启"推荐版本号"功能后出现
BK_CI_BUILD_NO 流水线里唯一,构建号,开启"推荐版本号"功能后出现,可以设置不同的自增规则
BK_CI_PIPELINE_UPDATE_USER 流水线更新用户
BK_CI_PIPELINE_VERSION 流水线版本号
BK_CI_PROJECT_NAME_CN 流水线对应的项目名称
BK_CI_START_CHANNEL 流水线启动的 CHANNEL CODE
BK_CI_START_USER_ID 流水线构建真正执行的用户 ID, 一般手动启动时的当前用户 ID,重试流水线人的用户 ID。如果是定时/webhook/子流水线调用, 则是流水线的最后修改人
BK_CI_START_USER_NAME 流水线构建启动的用户 ID, 通常值与 BK_CI_START_USER_ID 是一致的,但以下两种情况例外:1.当启动方式为 WEBHOOK,该值为 Git/SVN 的用户 ID;2.当是子流水线调用时,该值为父流水线的构建启动人 ID 例如:parent1 和 Sub2 的最后修改人为 User0;user1 手工执行 parent1 父流水线,parent1 再启动子流水线 Sub2, 此时 Sub2 的 BK_CI_START_USER_ID 为 User0;BK_CI_START_USER_NAME 为 User1
BK_CI_PARENT_PIPELINE_ID 获取启动当前流水线的父流水线 ID,仅当作为子流水线并被父流水线触发时才有效
BK_CI_PARENT_BUILD_ID 获取启动当前流水线的父流水线的构建 ID,仅当作为子流水线并被父流水线触发时才有效
BK_CI_START_PIPELINE_USER_ID 获取启动当前流水线的父流水线启动人,仅当作为子流水线并被父流水线触发时才有效
BK_CI_START_WEBHOOK_USER_ID 获取启动当前流水线的触发 Webhook 账号,仅当被 webhook 触发时才有效,该值将会展示在执行历史中,但实际执行人不是他,而是最后流水线修改人
BK_CI_RETRY_COUNT 重试的次数,默认不存在, 当出现失败重试/rebuild 时, 该变量才会出现,并且+1
BK_CI_ATOM_VERSION 当前插件版本号,如 1.0.1
BK_CI_ATOM_CODE 当前插件标识
BK_CI_TASK_NAME 当前步骤别名
BK_CI_ATOM_NAME 当前插件名称

预定义变量

可以在流水线运行过程中,设置流水线备注

Variable Description 样例
BK_CI_BUILD_REMARK 流水线构建备注信息,在流水线运行时通过 setEnv "BK_CI_BUILD_REMARK" 设置

GITHUB 常量合集

GITHUB拉取代码

Variable Description
git. g r o u p . {group}. group.{project}.new.commit
git. g r o u p . {group}. group.{project}.last.commit

GITHUB触发事件公共常量

Variable Description
BK_CI_REPO_WEBHOOK_REPO_TYPE 触发的代码库类型,为GIT
BK_CI_REPO_WEBHOOK_REPO_URL 触发的代码库URL
BK_CI_REPO_WEBHOOK_NAME 触发的代码库名称
BK_CI_REPO_WEBHOOK_ALIAS_NAME 触发的代码库在BK-CI的别名
BK_CI_REPO_WEBHOOK_HASH_ID 触发的代码库在BK-CI的HASH ID
BK_CI_REPO_GIT_WEBHOOK_COMMITID 触发对应的COMMIT ID
BK_CI_REPO_GIT_WEBHOOK_EVENT_TYPE 触发的事件类型
BK_CI_REPO_GIT_WEBHOOK_INCLUDE_BRANCHS 触发插件的监听的分支
BK_CI_REPO_GIT_WEBHOOK_EXCLUDE_BRANCHS 触发插件的排除的分支
BK_CI_REPO_GIT_WEBHOOK_EXCLUDE_USERS 触发插件的排除人员

GITHUB CREATE Branch Or Tag事件触发

Variable Description
BK_CI_REPO_GITHUB_WEBHOOK_CREATE_REF_NAME TAG或者BRANCH名称
BK_CI_REPO_GITHUB_WEBHOOK_CREATE_REF_TYPE REF类型,TAG或者BRANCH
BK_CI_REPO_GITHUB_WEBHOOK_CREATE_USERNAME 创建REF的作者

GITHUB Commit Push Hook事件触发

Variable Description
BK_CI_REPO_GIT_WEBHOOK_PUSH_USERNAME PUSH的用户
BK_CI_REPO_GIT_WEBHOOK_BRANCH PUSH对应的分支

GITHUB Pull Request Hook事件触发

Variable Description
BK_CI_REPO_GIT_WEBHOOK_MR_AUTHOR PR的作者或提交者
BK_CI_REPO_GIT_WEBHOOK_TARGET_URL PR的目标代码库URL
BK_CI_REPO_GIT_WEBHOOK_SOURCE_URL PR的源代码库URL
BK_CI_REPO_GIT_WEBHOOK_TARGET_BRANCH PR的目标分支
BK_CI_REPO_GIT_WEBHOOK_SOURCE_BRANCH PR的源分支
BK_CI_REPO_GIT_WEBHOOK_MR_CREATE_TIME PR的创建时间
BK_CI_REPO_GIT_WEBHOOK_MR_UPDATE_TIME PR的创建时间戳
BK_CI_REPO_GIT_WEBHOOK_MR_ID PR的ID
BK_CI_REPO_GIT_WEBHOOK_MR_NUMBER PR的更新时间戳
BK_CI_REPO_GIT_WEBHOOK_MR_DESC PR的描述
BK_CI_REPO_GIT_WEBHOOK_MR_TITLE PR的标题
BK_CI_REPO_GIT_WEBHOOK_MR_ASSIGNEE PR负责人
BK_CI_REPO_GIT_WEBHOOK_MR_URL PR的URL
BK_CI_REPO_GIT_WEBHOOK_MR_REVIEWERS PR的评审人(包括必要评审人)
BK_CI_REPO_GIT_WEBHOOK_MR_MILESTONE PR的里程碑名称
BK_CI_REPO_GIT_WEBHOOK_MR_MILESTONE_DUE_DATE PR的里程碑时间
BK_CI_REPO_GIT_WEBHOOK_MR_LABELS PR的标签

GIT常量合集

GIT拉取常量

Variable Description
BK_CI_GIT_REPO_URL 拉取代码库URL
BK_CI_GIT_REPO_NAME 拉取代码库名字
BK_CI_GIT_REPO_ALIAS_NAME 拉取代码库在BK-CI别名
BK_CI_GIT_REPO_BRANCH 拉取代码库分支
BK_CI_GIT_REPO_TAG 拉取代码库的TAG
BK_CI_GIT_REPO_CODE_PATH 拉取代码库的本地相对目录路径
BK_CI_GIT_REPO_LAST_COMMIT_ID 上一次构建的commit id
BK_CI_GIT_REPO_HEAD_COMMIT_ID 本次构建的commit id
BK_CI_GIT_REPO_HEAD_COMMIT_COMMENT 本次构建的提交注释
BK_CI_GIT_REPO_HEAD_COMMIT_AUTHOR 本次构建的author
BK_CI_GIT_REPO_HEAD_COMMIT_COMMITTER 本次构建的committer

GIT事件触发常量

Variable Description
BK_CI_REPO_WEBHOOK_REPO_TYPE 触发的代码库类型,为GIT
BK_CI_REPO_WEBHOOK_REPO_URL 触发的代码库URL
BK_CI_REPO_WEBHOOK_NAME 触发的代码库名称
BK_CI_REPO_WEBHOOK_ALIAS_NAME 触发的代码库在BK-CI的别名
BK_CI_REPO_WEBHOOK_HASH_ID 触发的代码库在BK-CI的HASH ID
BK_CI_REPO_GIT_WEBHOOK_COMMITID 触发对应的COMMIT ID
BK_CI_REPO_GIT_WEBHOOK_EVENT_TYPE 触发的事件类型
BK_CI_REPO_GIT_WEBHOOK_INCLUDE_BRANCH 触发插件的监听的分支
BK_CI_REPO_GIT_WEBHOOK_EXCLUDE_BRANCH 触发插件的排除的分支
BK_CI_REPO_GIT_WEBHOOK_INCLUDE_PATHS 触发插件的监听的路径
BK_CI_REPO_GIT_WEBHOOK_EXCLUDE_PATHS 触发插件的排除的路径
BK_CI_REPO_GIT_WEBHOOK_EXCLUDE_USERS 触发插件的排除的人员
BK_CI_GIT_WEBHOOK_FINAL_INCLUDE_BRANCH 插件配置"监听以下目标分支"中最终匹配的分支,如果没有配置值为空
BK_CI_GIT_WEBHOOK_FINAL_INCLUDE_PATH 插件配置"监听以下路径"中最终匹配的路径列表,如果没有配置值为空
BK_REPO_GIT_WEBHOOK_PUSH_COMMIT_MSG_n 触发的Commit日志。对于push事件n只等于1;对于mr事件n取值范围为1-32
BK_CI_HOOK_MESSAGE 触发时的commit message

GIT Commit Push Hook事件触发常量

Variable Description
BK_CI_REPO_GIT_WEBHOOK_PUSH_USERNAME PUSH的用户
BK_CI_REPO_GIT_WEBHOOK_BRANCH PUSH对应分支
BK_REPO_GIT_WEBHOOK_PUSH_BEFORE_COMMIT 本次PUSH前的commit id
BK_REPO_GIT_WEBHOOK_PUSH_AFTER_COMMIT 本次PUSH后的commit id
BK_REPO_GIT_WEBHOOK_PUSH_ADD_FILE_n1_n2 本次PUSH所添加的文件。n1表示第几个提交,n2表示提交中第几个文件,n取值范围为1-32
BK_REPO_GIT_WEBHOOK_PUSH_MODIFY_FILE_n1_n2 本次PUSH所变更的文件。n1表示第几个提交,n2表示提交中第几个文件,n取值范围为1-32
BK_REPO_GIT_WEBHOOK_PUSH_DELETE_FILE_n1_n2 本次PUSH所删除的文件。n1表示第几个提交,n2表示提交中第几个文件,n取值范围为1-32
BK_REPO_GIT_WEBHOOK_PUSH_ADD_FILE_COUNT 本次PUSH所添加的文件数量
BK_REPO_GIT_WEBHOOK_PUSH_MODIFY_FILE_COUNT 本次PUSH所变更的文件数量
BK_REPO_GIT_WEBHOOK_PUSH_DELETE_FILE_COUNT 本次PUSH所删除的文件数量

GIT Merge Request Hook 或 Merge Request Hook Accept事件触发常量

Variable Description
BK_CI_REPO_GIT_WEBHOOK_MR_AUTHOR Merge Request的作者或提交者
BK_CI_REPO_GIT_WEBHOOK_TARGET_URL Merge Request的目标代码库URL
BK_CI_REPO_GIT_WEBHOOK_SOURCE_URL Merge Request的源代码库URL
BK_CI_REPO_GIT_WEBHOOK_TARGET_BRANCH Merge Request的目标分支
BK_CI_REPO_GIT_WEBHOOK_SOURCE_BRANCH Merge Request的源分支
BK_CI_REPO_GIT_WEBHOOK_MR_CREATE_TIME Merge Request的创建时间
BK_CI_REPO_GIT_WEBHOOK_MR_UPDATE_TIME Merge Request的更新时间
BK_CI_REPO_GIT_WEBHOOK_MR_CREATE_TIMESTAMP Merge Request的创建时间戳
BK_CI_REPO_GIT_WEBHOOK_MR_UPDATE_TIMESTAMP Merge Request的更新时间戳
BK_CI_REPO_GIT_WEBHOOK_MR_ID 触发的Merge Request Id
BK_CI_REPO_GIT_WEBHOOK_MR_NUMBER 触发的Merge Request Number
BK_CI_REPO_GIT_WEBHOOK_MR_DESC Merge Request的描述
BK_CI_REPO_GIT_WEBHOOK_MR_TITLE Merge Request的标题
BK_CI_REPO_GIT_WEBHOOK_MR_ASSIGNEE Merge Request负责人
BK_CI_REPO_GIT_WEBHOOK_MR_URL Merge Request的URL
BK_CI_REPO_GIT_WEBHOOK_MR_REVIEWERS Merge Request的评审人(包括必要评审人)
BK_CI_REPO_GIT_WEBHOOK_MR_MILESTONE Merge Request的里程碑名称
BK_CI_REPO_GIT_WEBHOOK_MR_MILESTONE_DUE_DATE Merge Request的里程碑时间
Merge Request的里程碑时间 Merge Request的标签
BK_CI_REPO_GIT_WEBHOOK_COMMITID Merge Request的ID
BK_REPO_GIT_WEBHOOK_MR_LAST_COMMIT Merge Request最后一个提交的commitId
BK_REPO_GIT_WEBHOOK_MR_LAST_COMMIT_MSG Merge Request最后一个提交的提交信息

GIT Tag Push Hook事件触发

Variable Description
BK_CI_REPO_GIT_WEBHOOK_TAG_NAME 提交的TAG名字
BK_CI_REPO_GIT_WEBHOOK_TAG_OPERATION TAG操作:创建或删除(create/delete)
BK_CI_REPO_GIT_WEBHOOK_TAG_USERNAME 提交的TAG的作者
BK_REPO_GIT_WEBHOOK_TAG_CREATE_FROM 从哪个分支或者commit点创建,如果从客户端创建的tag,值为空

GIT Code Review Hook事件触发

Variable Description
BK_CI_REPO_GIT_WEBHOOK_REVIEW_REVIEWABLE_TYPE 如果是MR创建的CR,值为merge_request
BK_CI_REPO_GIT_WEBHOOK_REVIEW_REVIEWABLE_ID 如果是MR创建的CR,值为mr id
BK_CI_REPO_GIT_WEBHOOK_REVIEW_RESTRICT_TYPE 评审规则
BK_CI_REPO_GIT_WEBHOOK_REVIEW_APPROVING_REVIEWERS 未评审人列表,以,分割
BK_CI_REPO_GIT_WEBHOOK_REVIEW_APPROVED_REVIEWERS 已评审人列表,以,分割

GIT ISSUE事件触发

Variable Description
BK_CI_REPO_GIT_WEBHOOK_ISSUE_TITLE issue标题
BK_CI_REPO_GIT_WEBHOOK_ISSUE_ID issue id
BK_CI_REPO_GIT_WEBHOOK_ISSUE_IID issue iid
BK_CI_REPO_GIT_WEBHOOK_ISSUE_DESCRIPTION issue描述
BK_CI_REPO_GIT_WEBHOOK_ISSUE_STATE issue状态
BK_CI_REPO_GIT_WEBHOOK_ISSUE_OWNER issue创建者
BK_CI_REPO_GIT_WEBHOOK_ISSUE_URL issue url
BK_CI_REPO_GIT_WEBHOOK_ISSUE_MILESTONE_ID issue 里程碑id
BK_CI_REPO_GIT_WEBHOOK_ISSUE_ACTION issue操作

GIT Note事件触发

Variable Description
BK_CI_REPO_GIT_WEBHOOK_NOTE_COMMENT 评论内容
BK_CI_REPO_GIT_WEBHOOK_NOTE_ID 评论ID
BK_CI_REPO_GIT_WEBHOOK_NOTE_NOTEABLE_TYPE 评论类型,有Review、Commit、Issue
BK_CI_REPO_GIT_WEBHOOK_NOTE_AUTHOR_ID 评论作者
BK_CI_REPO_GIT_WEBHOOK_NOTE_CREATED_AT 评论创建时间
BK_CI_REPO_GIT_WEBHOOK_NOTE_UPDATED_AT 评论更新时间
BK_CI_REPO_GIT_WEBHOOK_NOTE_URL 评论url

自定义流水线变量

可以在编排流水线过程中,将通用的设置、运行过程中动态变更的参数提取为流水线变量。

在编排中自定义流水线全局变量

在编辑流水线页面点击 Job1-1,可以添加流水线变量。

(推荐)在 Bash/RunScript 插件中使用set-variable方式设置全局变量

您可以通过 Shell Script 插件中的 特定的语法echo "::set-variable name=<var_name>::"设置插件间传递的参数,用法如下:

shell 复制代码
#!/usr/bin/env bash
# echo "::set-variable name=<var_name>::<value>"
# eg:
# echo "::set-variable name=fooBarVarName::fooBarVarValue"
  • set-variable 设置的也是全局变量,如果两个Bash并发设置同名变量,设置结果不可预期
    通过此方法设置的变量,在下游通过表达式引用:${{ variables.fooBarVarName }}
  • 在 stage/job/task的流程控制条件中引用时,也是通过 variables.xxx 的方式来引用,如:

(推荐)在 Bash/RunScript 插件中使用set-outputs方式设置对应步骤的输出

您可以通过 Shell Script 插件中的 特定的语法echo "::set-output name=<output_name>::"设置插件间传递的参数,用法如下:

shell 复制代码
#!/usr/bin/env bash
# echo "::set-output name=<output_name>::<value>"
# eg:
# echo "::set-output name=outputVarName::outputVarValue"

通过此方法设置的输出变量,不会被任何步骤的同名输出覆盖。

使用此方法时,需设置对应步骤的id:

用于下游步骤引用此变量:

  • 当在 job2 中访问前置的 job1 的 step_set_var 的输出 outputVarName 时:${{ jobs.job1.steps.step_set_var.outputs.outputVarName }}
  • 当在 job2 中访问当前 job 下的 step_set_var 的输出 outputVarName 时,无需加 jobs 上下文,直接通过 steps 引用:${{ steps.step_set_var.outputs.outputVarName }}
  • 在 stage/job/task的流程控制条件中引用时,变量名也需配置为 jobs.job1.steps.step_set_var.outputs.outputVarName 的格式
    job id 在 job 配置上管理:(系统设置了一个默认值,可以修改为自己想要的id。需保证流水线下唯一)

Triggers

一般触发方式

BK-CI 支持多种方式触发流水线:

  • API 触发
  • 代码库事件触发
  • 子流水线调用插件触发
  • 定时触发
  • 手动触发
  • 远程触发
    不同的触发方式下,系统内置的 BK_CI_START_TYPE 取值也不同,你可以根据需要在流水线后续插件中使用该值:
触发方式 BK_CI_START_TYPE 值
远程触发 REMOTE
手动触发 MANUAL
定时触发 TIME_TRIGGER
子流水线插件触发 PIPELINE
代码库HOOK触发 WEB_HOOK
API触发 SERVICE

github事件触发

如果您需要GitHub事件触发,您需要在部署BK-CI时额外申请一个GitHub APP。

需要将如下相应变量,填充到bkenv.properties 配置文件中, 再重新render_tpl生成配置文件

BK-CI 云托管的构建资源

为了更友好的接入 CI,提供了包含以下类型的公共构建资源,可放心使用。

Linux Docker 母机

在部署好 BK-CI 之后默认内置的公共构建资源(如无法选择,请联系你的 CI 平台管理员),我们会在你的物理机/虚拟机上运行 Docker 服务来运行你的 CI 编译镜像,你只需要在流水线里指定一个镜像地址即可开始编译。

自定义 CI 镜像

在 dockerhub 上内置了两个最基础的 CI docker 镜像:

image dockerfile
bkci/ci:latest https://github.com/ci-plugins/base-images/blob/master/ci-build/Dockerfile
bkci/ci:alpine https://github.com/ci-plugins/base-images/blob/master/ci-build-less/Dockerfile

你也可以将这两个镜像作为基础镜像来制作你自己的 CI 镜像,当然,这需要一点点 Docker build相关知识。

制作自定义 CI 镜像请参考:构建并托管一个 CI 镜像

私有构建资源

除了公共编译资源外,你也可以将自己正在使用的 Linux/macOS/Windows 电脑作为私有构建资源托管至 BK-CI。

托管前,请先准备好执行环境:私有构建机环境准备

导入方法:服务-环境管理-节点页面,点击右上角的导入私有构建机:

根据弹窗:

  1. 选择机器的系统,不同操作系统安装命令和安装方法不一样(windows可参考导入windows构建机);
  2. 复制安装 Agent 的命令,在你的构建机的目标工作空间中执行该命令,进行 Agent 的下载和安装
  3. 安装完 Agent 以后,点击刷新,刷新出节点,点击导入即可。

流水线编辑页

流水线的核心页面之一,可通过可视化界面生成 CI 流水线。

功能区介绍

  1. 流水线面包屑:此处有两个点击事件
  • 点击流水线名称:快速进入流水线执行历史
  • 点击名称右侧的小三角:快速切换至其它流水线
  1. 流水线编辑标签,可以在流水线编排页、基础设置之间互相切换:
  • 流水线编排区:参考第 3 点
  • 流水线基础设置:
  1. 流水线编排区:遵守 流水线核心理念的可视化编排区域
  2. 流水线操作区,包含如下常用操作集合:
  • 保存:每点一次保存,会生成一个从 1 开始自增的编排版本号,可用于回滚
  • 执行:基于当前的编排版本号,生成一个快照流水线任务
  • 重命名:对当前流水线名称进行改名
  • 收藏:将当前流水线收藏,可以在"我的收藏"视图中查看
  • 导出:将当前流水线导出为 JSON,可以在新建流水线时导入(可跨不同项目)
  • 复制为:基于当前流水线的当前编排版本号,复制一个新的流水线"旧流水线名称_copy"
  • 另存为模板:将当前流水线的编排保存为流水线模板
  • 删除:软删除,将放入流水线回收站

关联第一个代码库

请按照如下步骤将你的代码库关联至 BK-CI(这里以 gitlab 为例):

  1. 切换至代码库服务
  2. 选择关联 Gitlab 代码库(如果凭据为空时,可以点击"新增"去增加凭据)


    演示下增加凭证:

    新建完会出现access token凭证:

相关推荐
不会飞的小龙人2 小时前
Docker Compose创建镜像服务
linux·运维·docker·容器·镜像
不会飞的小龙人2 小时前
Docker基础安装与使用
linux·运维·docker·容器
小歆8844 小时前
100%全国产化时钟服务器、全国产化校时服务器、全国产化授时服务器
运维·服务器
翻滚吧键盘5 小时前
debian中apt的配置与解析
运维·debian
workingman_li5 小时前
centos虚拟机异常关闭,导致数据出现问题
linux·运维·centos
Jackson~Y6 小时前
Linux(LAMP)
linux·运维·服务器
不知 不知6 小时前
最新-CentOS 7安装1 Panel Linux 服务器运维管理面板
linux·运维·服务器·centos
晚秋贰拾伍8 小时前
设计模式的艺术-职责链模式
运维·设计模式·运维开发·责任链模式·开闭原则·单一职责原则
花糖纸木9 小时前
【Linux】深刻理解动静态库
linux·运维·服务器
运维实战课程9 小时前
docker安装elk6.7.1-搜集nginx-json日志
linux·运维·服务器