Renovate 在 Bitbucket Cloud 上运行API Token 认证、平台专属配置与能力边界【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate本文围绕 Renovate 仓库中 Bitbucket Cloud 平台文档 展开讲解如何在 Bitbucket Cloud 上以自托管方式运行 RenovateAPI Token 的权限范围与三种注入凭证的方式、Renovate 为 Bitbucket 提供的专属配置项默认评审人、PR 任务自动完成、开发分支以及 Bitbucket Cloud 因平台机制缺失而不支持的功能。读完本文你将能独立完成 Bitbucket Cloud 上的 Renovate 接入配置并从 平台实现源码 中理解每一项限制背后的真实原因。运行方式托管应用 vs 自托管对绝大多数用户来说最简单的启动方式是安装 Atlassian Marketplace 上的 Mend 应用Mend app for Bitbucket并使用其免费 Renovate 计划。使用托管应用时Mend 会替你完成三件事将应用认证到 Bitbucket Cloud安全地保管访问令牌维护并更新所运行的 Renovate 版本。如果你选择自托管 Renovate则上述所有事项都必须自己完成。自托管面向的是有高级使用场景、或者希望完全掌控 Renovate 及其运行环境的用户官方建议大多数用户直接安装 Mend 应用。安装托管应用后可继续阅读 安全与权限说明 和 阅读清单 来了解如何使用与配置 Renovate。认证API Token 权限范围与凭证注入创建 API Token 及其所需权限自托管的第一步是为 Renovate 专用账号创建一个 Bitbucket Cloud API Token并赋予以下权限范围权限ScopeBitbucket 中的权限名称read:repository:bitbucketRepository: Readwrite:repository:bitbucketRepository: Writeread:pullrequest:bitbucketPull requests: Readwrite:pullrequest:bitbucketPull requests: Writeread:user:bitbucketUser: Readread:workspace:bitbucketWorkspace: Read此外Renovate 还需要校验 PR 评审人reviewer的 workspace 成员身份因此需要在 workspace 中创建一个具有Create repositories权限的用户组并把 Renovate 账号加入该组。从源码看这一校验发生在 createPr/updatePr 的评审人清洗流程 中当 Bitbucket 返回 400 错误提示某账号“不是该 workspace 的成员”时Renovate 会逐个调用/2.0/workspaces/{workspace}/members/{uuid}接口见 isAccountMemberOfWorkspace重新过滤评审人列表并重试。让 Renovate 使用你的 Token文档给出三种“三选一”的凭证注入方式在config.js中把 API Token 设置为password设置环境变量RENOVATE_PASSWORD通过 CLI 参数--password在运行时传入。同时不要遗漏两点username必须设置为 Renovate 账号名即你的 Atlassian 账号邮箱可在 Bitbucket 个人设置的 “Email aliases” 页面查到在 Renovate 配置文件的任意位置设置platformbitbucket。源码中的认证细节平台初始化入口 initPlatform 要求“token 与 usernamepassword 二者至少其一”否则会抛出Init: You must configure either a Bitbucket token or username and password。它还做了两件值得注意的事若你把endpoint配置成非默认的https://api.bitbucket.org/Renovate 会打出一条警告Bitbucket Cloud 的 endpoint 通常应保持默认怀疑用户实际想用 Bitbucket Server初始化时调用/2.0/user获取当前账号的 UUIDinitPlatform。若返回 403 且错误体中包含account范围缺失信息会明确告警 “missing account scope for password”。该 UUID 随后作为 PR 缓存的作者过滤条件见下文。真正克隆仓库时initRepo 会根据凭证类型构造三种不同的 Git 认证形式源码 L304-L311有token时使用x-token-auth:{token}password以ATAT开头API Token 的格式特征时使用x-bitbucket-api-token-auth:{password}否则退化为标准的username:passwordBasic 认证。同时它会把 API 域名api.bitbucket.org换算为实际的 Git 主机名bitbucket.org。如果仓库接口返回 404则抛出REPOSITORY_NOT_FOUND错误。Bitbucket 专属配置项Renovate 为 Bitbucket 平台提供了三个以bb开头的配置项定义见 lib/config/options/index.tsbbUseDefaultReviewers默认true开启后创建 PR 时 Renovate 会先查询 Bitbucket 的effective-default-reviewers接口把仓库配置的默认评审人自动带上。对应实现在 createPr 中只有platformPrOptions.bbUseDefaultReviewers为真时才发起该查询并填充reviewers字段。相关测试用例见 index.spec.ts。bbAutoResolvePrTasks默认false开启后PR 创建成功时会自动把 Bitbucket 上未完成的 PR 任务tasks逐一标记为RESOLVED。实现位于 autoResolvePrTasks先分页拉取/pullrequests/{id}/tasks再对每个未完成任务PUT更新其状态任何失败只会记录警告不阻断 PR 创建流程。bbUseDevelopmentBranch默认false仅全局配置开启后initRepo 会额外查询/2.0/repositories/{repo}/effective-branching-model如果仓库启用了 Bitbucket 的“开发分支”分支模型branching model就把该开发分支如develop当作 Renovate 的默认分支而不是仓库主分支。该选项标记为globalOnly: true只能在仓库级/全局配置中设置。仓库自动发现与 PR 缓存机制按 workspace 自动发现仓库启用autodiscoverRepositories时getRepos 的工作方式是若配置了autodiscoverNamespaces直接把这些命名空间当作 workspace slug否则先调用/2.0/user/workspaces分页拉取当前账号所属的全部 workspace再对每个 workspace 并行限并发查询/2.0/repositories/{workspace}汇总仓库列表。若配置了autodiscoverProjects还会按projectName做正则/glob 过滤。值得注意的是源码注释指出跨 workspace 的旧端点GET /2.0/repositories?rolecontributor已于 2026-03-31 被 Bitbucket 移除CHANGE-2770因此当前实现必须逐 workspace 查询——这是理解“为什么自动发现要按 workspace 进行”的关键背景。PR 列表缓存与增量同步Bitbucket 没有像 GitHub 那样的单一“列出某用户全部 PR”的高效接口Renovate 因此实现了 BitbucketPrCache缓存写入仓库级缓存repository cache的platform.bitbucket.pullRequestsCache中首次使用时全量同步一次请求覆盖全部状态OPEN、MERGED、DECLINED、SUPERSEDED并用fields参数只取需要的字段见 prFieldsFilter后续同步为增量查询条件附加updated_on 上次同步时间并按initPlatform获取的账号 UUID 附加author.uuid过滤每次运行内用内存缓存标记bitbucket-pr-cache-synced同一进程只同步一次缓存作者变更如更换账号时会整体重建。PR 状态在 utils.ts 的 prStates 中被归一化为 Renovate 通用状态closed对应DECLINED与SUPERSEDED其余按小写状态名映射。已关闭 PR 的“重开”信号Bitbucket 不支持重命名或重新打开已拒绝declined的 PR。为此 Renovate 改用评论信号findPr 发现处于closed状态的 PR 时会检查评论中是否以reopen!开头常量定义于 comments.ts。只有当评论者确实是 workspace 成员时私有仓库默认信任成员身份公开仓库则逐个校验才会返回 null让 Renovate 以一个全新的 PR 来“重开”更新。相应地PR 正文中所有“勾选 rebase/retry 复选框”的提示文案都会被 massageMarkdown 和 sanitizeCommentBody 改写为“将 PR 重命名为以rebase!开头”或“添加以reopen!开头的评论”。合并策略与分支状态检查支持的合并策略mergePr 的策略映射由 mergeBodyTransformer 完成squash→squash、merge-commit→merge_commit、fast-forward→fast_forward策略为auto或未指定时使用 Bitbucket 仓库内配置的合并策略。请求体始终携带close_source_branch: true。若策略为rebase函数直接返回false并记录警告——Bitbucket Cloud 至今没有 rebase 合并方式对应 Jira 单 BCLOUD-16610。因此automergeStrategyrebase在 Bitbucket Cloud 上不可用配置时请改用squash、merge-commit或fast-forward。分支状态检查getBranchStatus 先解析分支头 SHA再查询该 commit 的所有构建状态按以下规则归一化存在FAILED或STOPPED状态 →red存在INPROGRESS状态 →yellow全部成功但仅包含renovate/前缀的内部检查且internalChecksAsSuccess未开启→ 仍视为yellow避免“自己给自己的 PR 打绿”其余全部SUCCESSFUL→green无任何状态记录 →yellow。写入方向则由 setBranchStatus 完成Renovate 的绿/红/黄状态经 buildStates 映射为SUCCESSFUL/FAILED/INPROGRESSPOST 到/commit/{sha}/statuses/build并顺手使对应的状态缓存失效。注意 Bitbucket 要求url字段不能为空Renovate 会在缺省时回填https://bitbucket.org。不支持的平台特性完整清单文档明确列出以下 Bitbucket Cloud 的能力缺口源码中均有对应的降级处理逐项核对如下不支持给 PR 添加 assignee指派人。Bitbucket 只有 “participants” 与 “reviewers” 概念没有 assignee。addAssignees 只打印警告Cannot add assignees后空转返回同理deleteLabel也未实现源码注释 说明 Bitbucket Cloud 没有 PR label调用方永远不会走到该分支。automergeStrategyrebase不被支持平台 Jira 单 BCLOUD-16610见上文“合并策略”一节的源码说明。不支持可折叠collapsibleMarkdown 语法平台 Jira 单 BCLOUD-20231。为此 massageDetailSummaryHtmlToNestedLists 会把details/summary折叠块改写为嵌套无序列表summary文本替换为加粗或反引号包裹代码块缩进也会由 massageCodeblockMarkdown 规整确保 PR 正文在 Bitbucket 上正确渲染。此外 PR 正文上限为 25 万字符maxBodyLength超出的内容会被smartTruncate截断。Issues议题不再可用。Bitbucket Cloud 已于 2026-08-24 移除议题追踪器因此一切依赖 Issue 的功能随之失效包括Dependency Dashboard参见 Dependency Dashboard 配置项说明以及通过 Issue 提示 Renovate 配置警告的能力。源码中的体现非常直接findIssue、ensureIssue、getIssueList、ensureIssueClosing 全部是空实现stub——分别返回null、null、[]和空Promise并只记录一条一次性once日志说明议题追踪器已被移除。也就是说这些调用不会报错但 Dashboard 永远不会被创建。小结在 Bitbucket Cloud 上运行 Renovate 的检查清单综合文档与源码自托管 Renovate 到 Bitbucket Cloud 的核对项可以浓缩为创建专用账号与 API Token授予上文表格中的 6 个权限范围并建立含 Create repositories 权限的用户组配置platformbitbucket、usernameAtlassian 账号邮箱与凭证config.js的password、RENOVATE_PASSWORD或--password三选一endpoint 保持默认的https://api.bitbucket.org/否则 Renovate 会提示你可能误配成了 Bitbucket Server需要时按需开启bbUseDefaultReviewers默认已开、bbAutoResolvePrTasks、bbUseDevelopmentBranch避免使用automergeStrategyrebase并知悉 assignee 与 Dependency Dashboard 在 Bitbucket Cloud 上不可用与 Renovate 的日常交互采用 Bitbucket 专属信号重命名 PR 为rebase!前缀触发重试在已关闭 PR 下评论reopen!触发以新 PR 形式重开。以上行为均可在 lib/modules/platform/bitbucket/index.spec.ts 及 comments.spec.ts、pr-cache.spec.ts 的测试用例中找到对应验证。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Renovate 在 Bitbucket Cloud 上运行：API Token 认证、平台专属配置与能力边界
Renovate 在 Bitbucket Cloud 上运行API Token 认证、平台专属配置与能力边界【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate本文围绕 Renovate 仓库中 Bitbucket Cloud 平台文档 展开讲解如何在 Bitbucket Cloud 上以自托管方式运行 RenovateAPI Token 的权限范围与三种注入凭证的方式、Renovate 为 Bitbucket 提供的专属配置项默认评审人、PR 任务自动完成、开发分支以及 Bitbucket Cloud 因平台机制缺失而不支持的功能。读完本文你将能独立完成 Bitbucket Cloud 上的 Renovate 接入配置并从 平台实现源码 中理解每一项限制背后的真实原因。运行方式托管应用 vs 自托管对绝大多数用户来说最简单的启动方式是安装 Atlassian Marketplace 上的 Mend 应用Mend app for Bitbucket并使用其免费 Renovate 计划。使用托管应用时Mend 会替你完成三件事将应用认证到 Bitbucket Cloud安全地保管访问令牌维护并更新所运行的 Renovate 版本。如果你选择自托管 Renovate则上述所有事项都必须自己完成。自托管面向的是有高级使用场景、或者希望完全掌控 Renovate 及其运行环境的用户官方建议大多数用户直接安装 Mend 应用。安装托管应用后可继续阅读 安全与权限说明 和 阅读清单 来了解如何使用与配置 Renovate。认证API Token 权限范围与凭证注入创建 API Token 及其所需权限自托管的第一步是为 Renovate 专用账号创建一个 Bitbucket Cloud API Token并赋予以下权限范围权限ScopeBitbucket 中的权限名称read:repository:bitbucketRepository: Readwrite:repository:bitbucketRepository: Writeread:pullrequest:bitbucketPull requests: Readwrite:pullrequest:bitbucketPull requests: Writeread:user:bitbucketUser: Readread:workspace:bitbucketWorkspace: Read此外Renovate 还需要校验 PR 评审人reviewer的 workspace 成员身份因此需要在 workspace 中创建一个具有Create repositories权限的用户组并把 Renovate 账号加入该组。从源码看这一校验发生在 createPr/updatePr 的评审人清洗流程 中当 Bitbucket 返回 400 错误提示某账号“不是该 workspace 的成员”时Renovate 会逐个调用/2.0/workspaces/{workspace}/members/{uuid}接口见 isAccountMemberOfWorkspace重新过滤评审人列表并重试。让 Renovate 使用你的 Token文档给出三种“三选一”的凭证注入方式在config.js中把 API Token 设置为password设置环境变量RENOVATE_PASSWORD通过 CLI 参数--password在运行时传入。同时不要遗漏两点username必须设置为 Renovate 账号名即你的 Atlassian 账号邮箱可在 Bitbucket 个人设置的 “Email aliases” 页面查到在 Renovate 配置文件的任意位置设置platformbitbucket。源码中的认证细节平台初始化入口 initPlatform 要求“token 与 usernamepassword 二者至少其一”否则会抛出Init: You must configure either a Bitbucket token or username and password。它还做了两件值得注意的事若你把endpoint配置成非默认的https://api.bitbucket.org/Renovate 会打出一条警告Bitbucket Cloud 的 endpoint 通常应保持默认怀疑用户实际想用 Bitbucket Server初始化时调用/2.0/user获取当前账号的 UUIDinitPlatform。若返回 403 且错误体中包含account范围缺失信息会明确告警 “missing account scope for password”。该 UUID 随后作为 PR 缓存的作者过滤条件见下文。真正克隆仓库时initRepo 会根据凭证类型构造三种不同的 Git 认证形式源码 L304-L311有token时使用x-token-auth:{token}password以ATAT开头API Token 的格式特征时使用x-bitbucket-api-token-auth:{password}否则退化为标准的username:passwordBasic 认证。同时它会把 API 域名api.bitbucket.org换算为实际的 Git 主机名bitbucket.org。如果仓库接口返回 404则抛出REPOSITORY_NOT_FOUND错误。Bitbucket 专属配置项Renovate 为 Bitbucket 平台提供了三个以bb开头的配置项定义见 lib/config/options/index.tsbbUseDefaultReviewers默认true开启后创建 PR 时 Renovate 会先查询 Bitbucket 的effective-default-reviewers接口把仓库配置的默认评审人自动带上。对应实现在 createPr 中只有platformPrOptions.bbUseDefaultReviewers为真时才发起该查询并填充reviewers字段。相关测试用例见 index.spec.ts。bbAutoResolvePrTasks默认false开启后PR 创建成功时会自动把 Bitbucket 上未完成的 PR 任务tasks逐一标记为RESOLVED。实现位于 autoResolvePrTasks先分页拉取/pullrequests/{id}/tasks再对每个未完成任务PUT更新其状态任何失败只会记录警告不阻断 PR 创建流程。bbUseDevelopmentBranch默认false仅全局配置开启后initRepo 会额外查询/2.0/repositories/{repo}/effective-branching-model如果仓库启用了 Bitbucket 的“开发分支”分支模型branching model就把该开发分支如develop当作 Renovate 的默认分支而不是仓库主分支。该选项标记为globalOnly: true只能在仓库级/全局配置中设置。仓库自动发现与 PR 缓存机制按 workspace 自动发现仓库启用autodiscoverRepositories时getRepos 的工作方式是若配置了autodiscoverNamespaces直接把这些命名空间当作 workspace slug否则先调用/2.0/user/workspaces分页拉取当前账号所属的全部 workspace再对每个 workspace 并行限并发查询/2.0/repositories/{workspace}汇总仓库列表。若配置了autodiscoverProjects还会按projectName做正则/glob 过滤。值得注意的是源码注释指出跨 workspace 的旧端点GET /2.0/repositories?rolecontributor已于 2026-03-31 被 Bitbucket 移除CHANGE-2770因此当前实现必须逐 workspace 查询——这是理解“为什么自动发现要按 workspace 进行”的关键背景。PR 列表缓存与增量同步Bitbucket 没有像 GitHub 那样的单一“列出某用户全部 PR”的高效接口Renovate 因此实现了 BitbucketPrCache缓存写入仓库级缓存repository cache的platform.bitbucket.pullRequestsCache中首次使用时全量同步一次请求覆盖全部状态OPEN、MERGED、DECLINED、SUPERSEDED并用fields参数只取需要的字段见 prFieldsFilter后续同步为增量查询条件附加updated_on 上次同步时间并按initPlatform获取的账号 UUID 附加author.uuid过滤每次运行内用内存缓存标记bitbucket-pr-cache-synced同一进程只同步一次缓存作者变更如更换账号时会整体重建。PR 状态在 utils.ts 的 prStates 中被归一化为 Renovate 通用状态closed对应DECLINED与SUPERSEDED其余按小写状态名映射。已关闭 PR 的“重开”信号Bitbucket 不支持重命名或重新打开已拒绝declined的 PR。为此 Renovate 改用评论信号findPr 发现处于closed状态的 PR 时会检查评论中是否以reopen!开头常量定义于 comments.ts。只有当评论者确实是 workspace 成员时私有仓库默认信任成员身份公开仓库则逐个校验才会返回 null让 Renovate 以一个全新的 PR 来“重开”更新。相应地PR 正文中所有“勾选 rebase/retry 复选框”的提示文案都会被 massageMarkdown 和 sanitizeCommentBody 改写为“将 PR 重命名为以rebase!开头”或“添加以reopen!开头的评论”。合并策略与分支状态检查支持的合并策略mergePr 的策略映射由 mergeBodyTransformer 完成squash→squash、merge-commit→merge_commit、fast-forward→fast_forward策略为auto或未指定时使用 Bitbucket 仓库内配置的合并策略。请求体始终携带close_source_branch: true。若策略为rebase函数直接返回false并记录警告——Bitbucket Cloud 至今没有 rebase 合并方式对应 Jira 单 BCLOUD-16610。因此automergeStrategyrebase在 Bitbucket Cloud 上不可用配置时请改用squash、merge-commit或fast-forward。分支状态检查getBranchStatus 先解析分支头 SHA再查询该 commit 的所有构建状态按以下规则归一化存在FAILED或STOPPED状态 →red存在INPROGRESS状态 →yellow全部成功但仅包含renovate/前缀的内部检查且internalChecksAsSuccess未开启→ 仍视为yellow避免“自己给自己的 PR 打绿”其余全部SUCCESSFUL→green无任何状态记录 →yellow。写入方向则由 setBranchStatus 完成Renovate 的绿/红/黄状态经 buildStates 映射为SUCCESSFUL/FAILED/INPROGRESSPOST 到/commit/{sha}/statuses/build并顺手使对应的状态缓存失效。注意 Bitbucket 要求url字段不能为空Renovate 会在缺省时回填https://bitbucket.org。不支持的平台特性完整清单文档明确列出以下 Bitbucket Cloud 的能力缺口源码中均有对应的降级处理逐项核对如下不支持给 PR 添加 assignee指派人。Bitbucket 只有 “participants” 与 “reviewers” 概念没有 assignee。addAssignees 只打印警告Cannot add assignees后空转返回同理deleteLabel也未实现源码注释 说明 Bitbucket Cloud 没有 PR label调用方永远不会走到该分支。automergeStrategyrebase不被支持平台 Jira 单 BCLOUD-16610见上文“合并策略”一节的源码说明。不支持可折叠collapsibleMarkdown 语法平台 Jira 单 BCLOUD-20231。为此 massageDetailSummaryHtmlToNestedLists 会把details/summary折叠块改写为嵌套无序列表summary文本替换为加粗或反引号包裹代码块缩进也会由 massageCodeblockMarkdown 规整确保 PR 正文在 Bitbucket 上正确渲染。此外 PR 正文上限为 25 万字符maxBodyLength超出的内容会被smartTruncate截断。Issues议题不再可用。Bitbucket Cloud 已于 2026-08-24 移除议题追踪器因此一切依赖 Issue 的功能随之失效包括Dependency Dashboard参见 Dependency Dashboard 配置项说明以及通过 Issue 提示 Renovate 配置警告的能力。源码中的体现非常直接findIssue、ensureIssue、getIssueList、ensureIssueClosing 全部是空实现stub——分别返回null、null、[]和空Promise并只记录一条一次性once日志说明议题追踪器已被移除。也就是说这些调用不会报错但 Dashboard 永远不会被创建。小结在 Bitbucket Cloud 上运行 Renovate 的检查清单综合文档与源码自托管 Renovate 到 Bitbucket Cloud 的核对项可以浓缩为创建专用账号与 API Token授予上文表格中的 6 个权限范围并建立含 Create repositories 权限的用户组配置platformbitbucket、usernameAtlassian 账号邮箱与凭证config.js的password、RENOVATE_PASSWORD或--password三选一endpoint 保持默认的https://api.bitbucket.org/否则 Renovate 会提示你可能误配成了 Bitbucket Server需要时按需开启bbUseDefaultReviewers默认已开、bbAutoResolvePrTasks、bbUseDevelopmentBranch避免使用automergeStrategyrebase并知悉 assignee 与 Dependency Dashboard 在 Bitbucket Cloud 上不可用与 Renovate 的日常交互采用 Bitbucket 专属信号重命名 PR 为rebase!前缀触发重试在已关闭 PR 下评论reopen!触发以新 PR 形式重开。以上行为均可在 lib/modules/platform/bitbucket/index.spec.ts 及 comments.spec.ts、pr-cache.spec.ts 的测试用例中找到对应验证。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
