恒美微站
首页
关于我们
建站服务
主题模板
案例展示
资讯中心
联系我们
Danger JS 接入 BitBucket Cloud:账号配置、环境变量与 danger.bitbucket_cloud DSL 实战指南
首页
资讯中心
/
Danger JS 接入 BitBucket Cloud:账号配置、环境变量与 danger.bitbucket_cloud DSL 实战指南
Danger JS 接入 BitBucket Cloud:账号配置、环境变量与 danger.bitbucket_cloud DSL 实战指南
发布时间:2026/10/12 2:18:48
CI/CD代码评审开发工具【免费下载链接】danger-js⚠️ Stop saying you forgot to … in code review项目地址https://gitcode.com/gh_mirrors/da/danger-js点击查看免费下载本指南基于 danger-js 仓库中 docs/usage/bitbucket_cloud.html.md 编写讲解如何让 Danger 在 BitBucket Cloud 的 Pull Request 上自动发布代码审查反馈。你将掌握三种认证方式用户名密码、OAuth、仓库访问令牌的完整配置、danger.bitbucket_cloud对象的结构与用法以及底层 API 凭证解析与评论发布机制可直接应用到自己的 CI 流水线中。前置准备为 Danger 创建专用账号要让 Danger 在 BitBucket Cloud 上代发评论首先需要创建一个专门给 Danger 使用的 BitBucket Cloud 账号。这个账号不参与实际开发只负责以机器人的身份读取 Pull Request 信息、写入审查评论、更新构建状态。所有后续的认证凭证用户名、密码、OAuth 或仓库访问令牌都归属于该账号。三种认证方式与环境变量配置在 CI 上运行 Danger 时需要把以下环境变量按需配置到构建环境中。三种方式可以任选其一源码中的解析顺序是 OAuth 优先、其次用户名密码、最后仓库访问令牌详见 BitBucketCloudAPI.ts 的bitbucketCloudCredentialsFromEnv。方式一用户名 密码需要设置两个环境变量DANGER_BITBUCKETCLOUD_USERNAME用于代发评论的账号用户名可在 BitBucket 账户页面查看。DANGER_BITBUCKETCLOUD_PASSWORD该账号的密码。官方建议使用App passwords应用专用密码并为其授予两项权限Read Pull Requests读取 Pull Request与Read Account读取账户信息。从源码看用户名密码方式会在每次 API 请求时通过Authorization: Basic base64(username:password)头进行认证同时会调用https://api.bitbucket.org/2.0/user获取当前用户的 UUID用于识别 Danger 自己的评论。方式二OAuth Key Secret创建 OAuth consumer 的步骤如下打开 BitBucket Cloud 官网进入Settings OAuth Add consumer将 Callback URL 设置为https://bitbucket.org/site/oauth2/authorize勾选Read Pull requests与Read Account两项权限。然后配置两个环境变量DANGER_BITBUCKETCLOUD_OAUTH_KEY页面上显示的Key即 consumer keyDANGER_BITBUCKETCLOUD_OAUTH_SECRET页面上显示的Secret即 consumer secret。底层实现中BitBucketCloudAPI.tsDanger 会用 OAuth Key/Secret 组成 Basic 凭证向https://bitbucket.org/site/oauth2/access_token发起grant_typeclient_credentials的 POST 请求换取access_token之后所有 API 调用都携带Authorization: Bearer access_token。方式三仓库访问令牌Repository Access Token创建方式打开目标仓库的 URL进入Settings Security Access Tokens Create Repository Access Token为令牌命名并勾选Pull requests: write权限范围。对应环境变量DANGER_BITBUCKETCLOUD_REPO_ACCESSTOKEN创建好的仓库访问令牌。源码中该方式同样使用Authorization: Bearer accessToken头进行认证。需要注意的是仓库访问令牌的权限局限于单个仓库适合只在某一个仓库中运行 Danger 的场景。可选DANGER_BITBUCKETCLOUD_UUID仓库还支持可选的DANGER_BITBUCKETCLOUD_UUID环境变量用于显式指定 Danger 机器人的用户 UUID。源码规定该值必须用花括号包裹例如{1234-1234-1234-1234}否则会抛出DANGER_BITBUCKETCLOUD_UUID must be wraped with brackets错误见 BitBucketCloudAPI.ts。Danger 用它来过滤出自己发布过的评论实现结果更新与问题修复后删除评论。凭证解析的优先级与报错bitbucketCloudCredentialsFromEnv的判定逻辑为若设置了DANGER_BITBUCKETCLOUD_OAUTH_KEY则要求同时存在DANGER_BITBUCKETCLOUD_OAUTH_SECRET否则报DANGER_BITBUCKETCLOUD_OAUTH_SECRET is not set否则若设置了DANGER_BITBUCKETCLOUD_USERNAME则要求同时存在DANGER_BITBUCKETCLOUD_PASSWORD否则报DANGER_BITBUCKETCLOUD_PASSWORD is not set否则若设置了DANGER_BITBUCKETCLOUD_REPO_ACCESSTOKEN则使用仓库令牌三者皆无时抛出错误Either DANGER_BITBUCKETCLOUD_OAUTH_KEY, DANGER_BITBUCKETCLOUD_USERNAME or DANGER_BITBUCKETCLOUD_REPO_ACCESSTOKEN is not set。此外当 API 请求返回 4xx 状态码时源码会附加提示(Have you allowed permission account for this credential?)或(Have you set DANGER_BITBUCKETCLOUD_USERNAME or DANGER_BITBUCKETCLOUD_OAUTH_KEY?)用于引导排查权限配置问题BitBucketCloudAPI.ts 与 BitBucketCloudAPI.ts。在 CI 中启用 Danger以 Bitbucket Pipelines 为例仓库自带了 Bitbucket Pipelines 的 CI 集成实现BitbucketPipelines.ts它通过识别BITBUCKET_BUILD_NUMBER判定是否在 Pipelines 中以及BITBUCKET_GIT_HTTP_ORIGIN、BITBUCKET_REPO_OWNER、BITBUCKET_REPO_SLUG、BITBUCKET_PR_ID判定是否为 PR 构建来自动启用。典型的bitbucket-pipelines.yml配置如下image: node:10.15.0 pipelines: pull-requests: **: - step: caches: - node script: - export LANGC.UTF-8 - yarn install - yarn danger ci definitions: caches: node: node_modules要点说明在pull-requests流水线中运行danger ciDanger 会基于当前 PR 环境生成 DSL 并执行 Dangerfile通过caches缓存node_modules可提升构建速度在 Bitbucket Pipelines 的仓库设置Repository variables中把上一节的环境变量如DANGER_BITBUCKETCLOUD_USERNAME/DANGER_BITBUCKETCLOUD_PASSWORD或 OAuth 组合配置为受保护的变量避免明文泄露。其他 CI 系统如 Jenkins、CircleCI 等也可使用Danger 会自动从环境中识别 CI 来源见 get_ci_source.ts 的getCISourceForEnv只要对应的 CI 环境变量存在即可。在 Dangerfile 中使用 danger.bitbucket_cloud完成认证与 CI 配置后Danger 会在每次运行时向 BitBucket Cloud API 拉取当前 PR 的数据组装成完整的danger.bitbucket_cloud对象注入到 Dangerfile 中。一个最小示例import { danger, warn } from danger if (danger.bitbucket_cloud.pr.title.includes(WIP)) { warn(PR is considered WIP) }当 PR 标题包含 WIP 时Danger 会在 PR 上发布一条 warning 评论。DSL 对象全景danger.bitbucket_cloud对象包含以下五个核心字段类型定义见 BitBucketCloudDSL.tsdanger.bitbucket_cloud. /** 当前 PR 与仓库元数据 */ metadata: RepoMetaData /** PR 元数据标题、状态、来源/目标分支等 */ pr: BitBucketCloudPRDSL /** 与该 PR 关联的提交列表 */ commits: BitBucketCloudCommit[] /** 该 PR 上的评论 */ comments: BitBucketCloudPRComment[] /** 该 PR 的活动记录OPENING、COMMENTING、CLOSING、MERGING、UPDATING 等 */ activities: BitBucketCloudPRActivity[]这些数据在 BitBucketCloud.ts 的getPlatformReviewDSLRepresentation中通过一次并发拉取组装getPullRequestInfo()、getPullRequestCommits()、getPullRequestComments()、getPullRequestActivities()均使用 Bitbucket Cloud API 2.0 的分页接口/repositories/{workspace}/{repo}/pullrequests/{id}/...。如果获取 PR 信息失败Danger 会设置退出码 1 并提示 Could not find pull request information, perhaps Danger does not have permission to access the repo.。关键子对象详解RepoMetaDataRepoMetaData.ts仅含两个字段——repoSlug形如workspace/repo_slug的完整路径与pullRequestIDPR 的数字 ID。BitBucketCloudPRDSLBitBucketCloudDSL.ts包含id、title、descriptionPR 编号、标题、描述stateOPEN | MERGED | DECLINED | SUPERSEDED即 PR 当前状态created_on/updated_on创建与更新时间ISO 8601 格式source/destinationBitBucketCloudMergeRef含commit.hash、branch.name、repository仓库名、full_name、uuidauthorPR 创建者含uuid、display_name、nickname、account_idreviewers受邀审查者列表participants参与人员含role: REVIEWER | PARTICIPANT与approved布尔值links指向 decline、commits、comments、merge、diff、approve、statuses 等端点的超媒体链接。BitBucketCloudCommitBitBucketCloudDSL.tshashSHA、author含raw: Foo Bar foobar.com格式的原始作者串与用户信息、date、message、parents父提交哈希数组、links。在 BitBucketCloudGit.ts 中这些提交会被转换为通用的GitCommit供danger.git使用。BitBucketCloudPRCommentBitBucketCloudDSL.ts评论内容contentraw/markup/html、user、created_on、updated_on、inline可选的行内定位to、from、path等。注意 Danger 的审查结果评论通过content.raw中包含的danger-id-dangerID;签名来识别见 bitbucketCloudTemplate.ts。借助 API 对象扩展能力danger.bitbucket_cloud上还挂载了一个已认证的api对象BitBucketCloudDSL.ts允许你在 Dangerfile 里直接调用 Bitbucket Cloud 的 REST APIgetFileContents(filePath, repoSlug?, refspec?)读取仓库中某个文件在指定 commit 下的内容默认取当前 PR 的 source 分支与最新 commitget(path, headers?, suppressErrors?)、post(path, headers?, body?, suppressErrors?)、put(...)、delete(...)对 Bitbucket Cloud API 2.0 发起 HTTP 请求。例如可以读取 PR 中修改的某个配置文件来做一致性校验import { danger, fail } from danger const lockfile await danger.bitbucket_cloud.api.getFileContents(yarn.lock) if (!lockfile) { fail(yarn.lock 不存在或无法读取) }Danger 评论的生命周期发布、更新与清理Danger 在 BitBucket Cloud 上的评论管理基于danger-id签名机制BitBucketCloud.ts 的updateOrCreateComment首次运行若该 PR 上不存在 Danger 的评论则新建一条主评论再次运行找到已有的主评论并就地更新PUT同时删除重复的历史评论保证 PR 上始终只有一条最新结果当所有问题都修复后删除整条主评论deleteMainComment让 PR 保持整洁。评论内容的渲染由 bitbucketCloudTemplate.ts 完成无 Fails 与 Warnings 时输出:tada: All green.及随机表扬语有问题时按 Fails、Warnings、Messages 三个 Markdown 表格分区展示末尾附带 Generated by … 签名。模板支持 BitBucket Cloud 的表情符号:x:、:warning:、:sparkles:、:tada:等。此外BitBucket Cloud 平台还支持行内评论supportsInlineComments()返回 true。当在 Dangerfile 中对具体文件行使用message/warn/fail并附带文件路径时Danger 会调用postInlinePRComment在对应代码行上发布评论并通过inline字段to行号 path文件路径定位见 BitBucketCloudAPI.ts。构建状态上报Danger 还能把检查结果以build status的形式挂到 PR 的 source commit 上updateStatus见 BitBucketCloud.ts映射关系为Danger 结果Bitbucket 状态通过passedtrueSUCCESSFUL失败passedfalseFAILED运行中pendingINPROGRESS状态请求会 POST 到{baseURL}/repositories/{repo}/commit/{commitId}/statuses/build默认 name 为Danger、key 为danger.systems当设置了dangerID时 name/key 会替换为该 ID。这让你可以在 BitBucket 的 PR 页面上直接看到 Danger 的检查通过/失败状态与 CI 的 Pipelines 结果并列展示。故障排查速查提示找不到 PR 信息多为 Danger 使用的账号缺少 Read Pull requests 权限或仓库访问令牌未勾选相应 scope认证报错 401/403 并提示 permission account说明凭证未授予 Read Account 权限用户名密码方式尤其需要确认 App password 勾选了 Read AccountDANGER_BITBUCKETCLOUD_UUID 报错UUID 必须以{开头、}结尾评论未更新确认 CI 中每次运行都使用了相同的dangerID默认基于 commit 生成Danger 依靠它识别自己的旧评论。以上配置与行为的实现依据可进一步查阅 BitBucketCloud.ts、BitBucketCloudAPI.ts、BitBucketCloudDSL.ts 以及对应的测试用例 _bitbucket_cloud.test.ts 与 _bitbucket_cloud_api.test.ts这些测试用例完整覆盖了凭证构造、API 端点调用与评论过滤逻辑可作为集成验证的参考。赞分享CI/CD代码评审开发工具【免费下载链接】danger-js⚠️ Stop saying you forgot to … in code review项目地址https://gitcode.com/gh_mirrors/da/danger-js点击查看免费下载相关推荐Woodpecker 集成 Bitbucket Datacenter / ServerOAuth2、服务账号与全套环境变量配置指南Woodpecker 集成 Bitbucket Datacenter / ServerOAuth2、服务账号与全套环境变量配置指南 本指南以 WoodpeckCI/CDDevOpsWoodpecker 接入 Bitbucket Cloud 完整指南OAuth 注册、环境变量配置与源码实现解析Woodpecker 接入 Bitbucket Cloud 完整指南OAuth 注册、环境变量配置与源码实现解析 本文基于 Woodpecker v3.16CI/CDDevOpsWoodpecker CI 集成 Bitbucket Cloud 完整指南OAuth 配置、环境变量与驱动原理Woodpecker CI 集成 Bitbucket Cloud 完整指南OAuth 配置、环境变量与驱动原理 Woodpecker CI 内置了对 BitbCI/CDDevOps上一篇FastF1 v2.1.6 版本解析新增天气数据支持与遥测/位置数据缺陷修复实战指南下一篇Optimism 仓库 Flake 防治实战op-acceptance-tests 与 op-devstack 的 17 类 CI 不稳定反模式、静态拦截与评审清单创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考