Backstage v1.38.0-next.1 版本解析Bitbucket Server 事件驱动目录增量同步与 Slack 通知处理器【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstage本篇文章基于当前仓库 docs/releases/v1.38.0-next.1-changelog.md 展开全面解析该预发布版本的核心变更Bitbucket Server 推送 Webhook 事件驱动目录增量同步delta mutation、GitHub Catalog 模块对含斜杠分支名的破坏性变更以及全新的 Slack 通知处理器。读完本文你将掌握这些新能力的安装步骤、配置项语义、底层实现原理以及升级到该版本时需要重点关注的破坏性变更与迁移动作。版本概览v1.38.0 的第二个预发布迭代v1.38.0-next.1 是 Backstage 迈向 v1.38.0 稳定版之前的第二个next预发布版本。它不属于面向生产环境的正式版本而是用于让社区在最终发布前验证新功能与破坏性变更。本次迭代的核心看点集中在三条主线上事件驱动的目录同步backstage/plugin-catalog-backend-module-bitbucket-server与全新的backstage/plugin-events-backend-module-bitbucket-server配合让 Bitbucket Server 的推送pushWebhook 能够触发 Catalog 的增量更新delta mutation破坏性变更backstage/plugin-catalog-backend-module-github开始显式拒绝包含斜杠/的分支名配置新能力模块backstage/plugin-notifications-backend-module-slack首次发布为 notifications 插件提供 Slack 通知处理器。其余变更以 Patch补丁为主涉及依赖升级与若干 Bug 修复覆盖了cli、core-components、scaffolder、techdocs、auth-backend等数十个包整体上为这些模块对齐了新的依赖基线。Bitbucket Server从 Webhook 到 Catalog 增量同步能力背景什么是 delta mutation在 Backstage 的软件目录Software Catalog中实体发现entity discovery通常依赖轮询式的实体提供器Entity Provider周期性扫描代码仓库。这种方式的实时性有限且会产生大量不必要的 API 调用。delta mutation增量变更机制允许外部事件——例如代码托管平台的 Webhook——直接告知 Catalog 某个仓库变了从而只针对受影响的实体做增量刷新而不是全量重扫。v1.38.0-next.1 为 Bitbucket Server 补齐了这条事件链路Webhook 事件 → 事件路由器 → Catalog 分析器 → 增量变更。新增的事件模块events-backend-module-bitbucket-serverbackstage/plugin-events-backend-module-bitbucket-server0.1.0-next.0是本次新增的独立模块其职责是把 Bitbucket Server 推送过来的原始 Webhook 事件接入 Backstage 的事件系统。从源码BitbucketServerEventRouter.ts可以看到它实现了一个SubTopicEventRouter订阅通用的bitbucketServer主题依据 Webhook 请求头中的x-event-key字段值将事件分发到更具体的子主题例如x-event-key: repo:refs_changed→ 子主题bitbucketServer.repo:refs_changedx-event-key: repo:modified→ 子主题bitbucketServer.repo:modified安装与接入方式详见 README.md# 在 Backstage 根目录下执行 yarn add --cwd packages/backend backstage/plugin-events-backend-module-bitbucket-server// packages/backend/src/index.ts backend.add(import(backstage/plugin-events-backend-module-bitbucket-server));Catalog 模块的增量同步0.4.0 的 Minor Changebackstage/plugin-catalog-backend-module-bitbucket-server0.4.0-next.0本次的 Minor Change提交 7b3ed9b正是与上述事件模块配套它现在能够接收来自 Bitbucket Server 推送 Webhook 的事件并对 Catalog 执行 delta mutation。事件到达 Catalog 侧后由 Webhook 分析器完成翻译。在 analyzeBitbucketServerWebhookEvent.ts 中支持的两种事件类型被映射为 Catalog 的 SCM 事件Bitbucket Server 事件x-event-key产生的 Catalog SCM 事件含义repo:refs_changedrepository.updated推送导致仓库变化触发该仓库的目录刷新repo:modifiedrepository.moved或repository.updated仓库被重命名时产生repository.moved携带fromUrl/toUrl其余元数据变更产生repository.updated值得注意的实现限制源码注释中已明确说明Bitbucket Server 的推送负载不包含文件级变更数据因此该分析器只产生仓库级事件与 GitLab、Azure DevOps 分析器可以发出细粒度location.*事件不同Bitbucket Server不提供仓库删除的 Webhook因此不会产生repository.deleted事件当事件缺少必要字段例如repo:refs_changed中缺少repository.links.self[0].href时分析结果标记为aborted未支持的事件类型返回unsupported-event。这解释了为什么目录增量同步以仓库为粒度触发的是该仓库实体的刷新而不是单个文件路径的增删改。端到端链路与配置提示要把这条链路真正跑起来通常需要安装上述两个模块events 模块 catalog 模块并在后端注册在 Bitbucket Server 侧配置仓库级 Webhook将其推送到 Backstage 的 events 接收端点确保 events 后端插件backstage/plugin-events-backend已安装events 模块是对它的扩展可参考其 README.md 中Install the events-backend plugin的说明检查x-event-key能正确传递到路由器的metadata中——因为子主题路由正是读取该字段完成分发的。破坏性变更GitHub Catalog 模块拒绝含斜杠的分支名backstage/plugin-catalog-backend-module-github0.8.0-next.1引入了一个BREAKING破坏性变更提交 f0c22eb模块现在显式拒绝任何包含斜杠字符的分支名配置。原因与影响根据 changelog 的说明之所以禁止斜杠是因为如果让这类分支名通过ingestion实体摄取会在下游处理中遇到问题。具体表现为如果你在filters.branch中配置了包含斜杠的分支名你的应用可能无法启动may fail to start up。这与 Git 分支命名习惯有直接关系feature/foo、release/1.2这类带斜杠的命名在 Git 中非常常见但在该模块的过滤匹配逻辑中会成为隐患因此版本选择直接拒绝这种更严格但更安全的策略。升级动作清单如果你正受此影响需要执行以下迁移检查配置在app-config.yaml或环境变量覆盖中搜索filters.branch下的分支名确认是否含/改名分支改用不含斜杠的分支名例如将release/1.2改为release-1.2启动验证升级后先本地启动后端确认应用能够正常初始化且 GitHub 仓库的实体摄取仍然符合预期。同版本周边更新同一个 Minor 版本还包含依赖升级backstage/integration1.16.3-next.0、backstage/plugin-catalog-backend1.32.1-next.0等。另外backstage/integration1.16.3-next.0本身有一个值得注意的 Patch提交 9768992GitHub 的webhookSecret配置属性被标记为可选——因为创建 GitHub App 时并不强制要求webhookSecret。这意味着集成配置的必填项收窄降低了 GitHub App 场景下的配置门槛。新模块Slack 通知处理器notifications-backend-module-slackbackstage/plugin-notifications-backend-module-slack0.1.0-next.0是本次版本首次发布的模块提交 552170d为 notifications 插件增加了一个Slack NotificationProcessor支持把 Backstage 通知通过 Slack 私信DM或频道消息发送出去。处理器在通知架构中的位置notifications 插件通过处理器Processor来扩展通知投递渠道。SlackNotificationProcessor实现了通知节点定义的NotificationProcessor接口注册到notificationsProcessingExtensionPoint之后会在通知发送流程的适当时机被调用详见模块装配代码 module.ts。配置项全解析配置位于app-config.yaml的notifications.processors.slack下是一个数组可以配置多个 Slack 工作区/机器人实例。完整的 Schema 定义见 config.d.ts参数说明如下配置项类型必填默认值说明tokenstring是—Slack Bot Token通常以xoxb-开头属于敏感配置visibility secretbroadcastChannelsstring[]否—广播通知的接收方可为 Slack 用户 ID、用户邮箱、频道名或频道 IDchat.postMessage接受的任意标识。已标记为 deprecated建议改用broadcastRoutesusernamestring否—通知显示的发送者名称broadcastRoutes对象数组否—基于 origin 和/或 topic 的广播路由按顺序求值、首个匹配生效见下文concurrencyLimitnumber否10每个后端实例的 Slack 通知并发上限throttleIntervalHumanDuration / string否1 分钟每个后端实例的 Slack 通知节流间隔broadcastRoutes中每个路由包含三个字段origin要匹配的来源例如plugin:catalog、external:my-servicetopic要匹配的主题例如entity-updated、alertschannel发送目标可为单个字符串或字符串数组频道 ID、频道名或用户 ID。路由的匹配优先级实现在 SlackNotificationProcessor.ts 的getBroadcastDestinations中origin topic 同时匹配最具体仅 origin 匹配仅 topic 匹配兜底回退到旧的broadcastChannels。配置示例notifications: processors: slack: - token: ${SLACK_BOT_TOKEN} username: Backstage Bot concurrencyLimit: 10 throttleInterval: minutes: 1 broadcastRoutes: - origin: plugin:scaffolder topic: task-completed channel: [C1234567890, #builds] - origin: external:monitoring channel: #alerts目标解析注解与邮箱回退处理器如何决定把通知发给哪个 Slack 目标核心是实体注解slack.com/bot-notify常量定义见 constants.ts。该注解的值可以是chat.postMessage接受的任意目标用户 ID如U12345678频道 ID如C12345678私信 ID如D12345678群组 ID如S12345678也支持邮箱地址或频道名但官方建议优先使用 ID。解析逻辑resolveSlackId优先读取实体的slack.com/bot-notify注解若实体是 User 且没有注解则通过其spec.profile.email调用 Slackusers.lookupByEmail反查 Slack ID均未命中则跳过该实体并记录 debug/error 日志。处理器还支持在通知文本中把形如user:default/billy的用户实体引用替换为 Slack 提及U12345678replaceUserRefsWithSlackIds并且通过 DataLoader 对实体查询做了批处理maxBatchSize: 100与 10 分钟缓存。更新语义scope 匹配与消息时间戳Slack 处理器对通知更新notification update有专门处理当一条通知携带origin和scope时处理器会在slack_message_timestamps表中记录已发送消息的时间戳ts。后续若同一originscope的通知发生更新会调用chat.update原地更新已有的 Slack 消息而不是再发一条新消息。这依赖一次数据库迁移见 module.ts 中的迁移逻辑并通过内置调度任务每 24 小时清理超过 24 小时保留期的旧时间戳记录。性能保护与可观测性模块内置了p-throttle节流concurrencyLimitthrottleInterval防止大批量接收用户的通知把系统阻塞三个 Prometheus 计数器指标notifications.processors.slack.sent.count发送成功数、notifications.processors.slack.error.count失败数、notifications.processors.slack.update.count通过 scope 匹配更新的消息数。扩展点自定义 Block Kit 渲染模块还暴露了一个扩展点notificationsSlackBlockKitExtensionPoint定义见 extensions.ts允许通过setBlockKitRenderer注册自定义渲染函数把NotificationPayload渲染为 Slack Block Kit 的KnownBlock[]从而定制消息的展示形式。扩展点只允许注册一次重复注册会抛错。值得关注的修复与其他更新本次预发布还包含若干功能性修复core-components5d7bad4修复了AlertDisplay中错误提示有更早的消息可用实为更新的消息的文案问题catalog-backend-module-bitbucket-cloud146e41b修复了事件驱动发现event-based discovery中导致对 Bitbucket Cloud 发起不必要 API 调用的问题catalog-import5b9514f因react-hook-form移除了UnpackNestedValue类型该插件改为自行导出该类型以保持兼容同时为Register an existing component文本补充了翻译f1d9a64scaffolder-backend-module-gitlab003dc15gitlab:group:ensureExistsaction 的path字段现在支持多段字符串如group/subgrouptechdocs-module-addons-contrib9c12a76修复ReportIssueaddon 在不支持的仓库类型下的渲染问题并改进了 Shadow DOM 内的事件处理techdocs-react0e9f7fe修复新前端系统下因多个 addons 数据附加导致 Catalog 实体文档页无法加载的问题auth-backend-module-bitbucket-provider5d10f99为 Bitbucket Cloud 启用了 scope 持久化integration-react同时为 Bitbucket Cloud 增加了projectscopekubernetesb877e46Kubernetes Tab 新增新前端系统过滤器使用isKubernetesAvailable控制可见性notifications-backend9a6080e允许对通知发送做节流避免海量接收用户时阻塞系统canonf7cb538 / 5e80f0b布局组件 prop 提取逻辑的内部重构与Icon组件类型修复。升级建议与验证清单由于这是预发布版本升级前请务必明确你的目标若需要验证上述新能力可在测试环境使用 Upgrade Helperchangelog 顶部提供的工具目标版本1.38.0-next.1生成升级指引若在生产环境建议等待 v1.38.0 正式版发布。重点检查以下三点GitHub 分支名扫描filters.branch配置移除所有含/的分支名否则后端可能无法启动Bitbucket Server 事件链路若你已经在用 Bitbucket Server 的 Catalog 模块确认是否要启用事件驱动的增量同步并按上文安装新增的 events 模块与配置 WebhookSlack 通知若希望启用 Slack 投递按notifications.processors.slack配置token等参数并确认实体注解slack.com/bot-notify或用户邮箱已就绪。如需深入了解相关模块的配置与实现可继续阅读仓库中的 processors.mdnotifications 处理器文档、events-backend-module-bitbucket-server 的 README 以及上文引用的源码文件。【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Backstage v1.38.0-next.1 版本解析Bitbucket Server 事件驱动目录增量同步与 Slack 通知处理器【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstage本篇文章基于当前仓库 docs/releases/v1.38.0-next.1-changelog.md 展开全面解析该预发布版本的核心变更Bitbucket Server 推送 Webhook 事件驱动目录增量同步delta mutation、GitHub Catalog 模块对含斜杠分支名的破坏性变更以及全新的 Slack 通知处理器。读完本文你将掌握这些新能力的安装步骤、配置项语义、底层实现原理以及升级到该版本时需要重点关注的破坏性变更与迁移动作。版本概览v1.38.0 的第二个预发布迭代v1.38.0-next.1 是 Backstage 迈向 v1.38.0 稳定版之前的第二个next预发布版本。它不属于面向生产环境的正式版本而是用于让社区在最终发布前验证新功能与破坏性变更。本次迭代的核心看点集中在三条主线上事件驱动的目录同步backstage/plugin-catalog-backend-module-bitbucket-server与全新的backstage/plugin-events-backend-module-bitbucket-server配合让 Bitbucket Server 的推送pushWebhook 能够触发 Catalog 的增量更新delta mutation破坏性变更backstage/plugin-catalog-backend-module-github开始显式拒绝包含斜杠/的分支名配置新能力模块backstage/plugin-notifications-backend-module-slack首次发布为 notifications 插件提供 Slack 通知处理器。其余变更以 Patch补丁为主涉及依赖升级与若干 Bug 修复覆盖了cli、core-components、scaffolder、techdocs、auth-backend等数十个包整体上为这些模块对齐了新的依赖基线。Bitbucket Server从 Webhook 到 Catalog 增量同步能力背景什么是 delta mutation在 Backstage 的软件目录Software Catalog中实体发现entity discovery通常依赖轮询式的实体提供器Entity Provider周期性扫描代码仓库。这种方式的实时性有限且会产生大量不必要的 API 调用。delta mutation增量变更机制允许外部事件——例如代码托管平台的 Webhook——直接告知 Catalog 某个仓库变了从而只针对受影响的实体做增量刷新而不是全量重扫。v1.38.0-next.1 为 Bitbucket Server 补齐了这条事件链路Webhook 事件 → 事件路由器 → Catalog 分析器 → 增量变更。新增的事件模块events-backend-module-bitbucket-serverbackstage/plugin-events-backend-module-bitbucket-server0.1.0-next.0是本次新增的独立模块其职责是把 Bitbucket Server 推送过来的原始 Webhook 事件接入 Backstage 的事件系统。从源码BitbucketServerEventRouter.ts可以看到它实现了一个SubTopicEventRouter订阅通用的bitbucketServer主题依据 Webhook 请求头中的x-event-key字段值将事件分发到更具体的子主题例如x-event-key: repo:refs_changed→ 子主题bitbucketServer.repo:refs_changedx-event-key: repo:modified→ 子主题bitbucketServer.repo:modified安装与接入方式详见 README.md# 在 Backstage 根目录下执行 yarn add --cwd packages/backend backstage/plugin-events-backend-module-bitbucket-server// packages/backend/src/index.ts backend.add(import(backstage/plugin-events-backend-module-bitbucket-server));Catalog 模块的增量同步0.4.0 的 Minor Changebackstage/plugin-catalog-backend-module-bitbucket-server0.4.0-next.0本次的 Minor Change提交 7b3ed9b正是与上述事件模块配套它现在能够接收来自 Bitbucket Server 推送 Webhook 的事件并对 Catalog 执行 delta mutation。事件到达 Catalog 侧后由 Webhook 分析器完成翻译。在 analyzeBitbucketServerWebhookEvent.ts 中支持的两种事件类型被映射为 Catalog 的 SCM 事件Bitbucket Server 事件x-event-key产生的 Catalog SCM 事件含义repo:refs_changedrepository.updated推送导致仓库变化触发该仓库的目录刷新repo:modifiedrepository.moved或repository.updated仓库被重命名时产生repository.moved携带fromUrl/toUrl其余元数据变更产生repository.updated值得注意的实现限制源码注释中已明确说明Bitbucket Server 的推送负载不包含文件级变更数据因此该分析器只产生仓库级事件与 GitLab、Azure DevOps 分析器可以发出细粒度location.*事件不同Bitbucket Server不提供仓库删除的 Webhook因此不会产生repository.deleted事件当事件缺少必要字段例如repo:refs_changed中缺少repository.links.self[0].href时分析结果标记为aborted未支持的事件类型返回unsupported-event。这解释了为什么目录增量同步以仓库为粒度触发的是该仓库实体的刷新而不是单个文件路径的增删改。端到端链路与配置提示要把这条链路真正跑起来通常需要安装上述两个模块events 模块 catalog 模块并在后端注册在 Bitbucket Server 侧配置仓库级 Webhook将其推送到 Backstage 的 events 接收端点确保 events 后端插件backstage/plugin-events-backend已安装events 模块是对它的扩展可参考其 README.md 中Install the events-backend plugin的说明检查x-event-key能正确传递到路由器的metadata中——因为子主题路由正是读取该字段完成分发的。破坏性变更GitHub Catalog 模块拒绝含斜杠的分支名backstage/plugin-catalog-backend-module-github0.8.0-next.1引入了一个BREAKING破坏性变更提交 f0c22eb模块现在显式拒绝任何包含斜杠字符的分支名配置。原因与影响根据 changelog 的说明之所以禁止斜杠是因为如果让这类分支名通过ingestion实体摄取会在下游处理中遇到问题。具体表现为如果你在filters.branch中配置了包含斜杠的分支名你的应用可能无法启动may fail to start up。这与 Git 分支命名习惯有直接关系feature/foo、release/1.2这类带斜杠的命名在 Git 中非常常见但在该模块的过滤匹配逻辑中会成为隐患因此版本选择直接拒绝这种更严格但更安全的策略。升级动作清单如果你正受此影响需要执行以下迁移检查配置在app-config.yaml或环境变量覆盖中搜索filters.branch下的分支名确认是否含/改名分支改用不含斜杠的分支名例如将release/1.2改为release-1.2启动验证升级后先本地启动后端确认应用能够正常初始化且 GitHub 仓库的实体摄取仍然符合预期。同版本周边更新同一个 Minor 版本还包含依赖升级backstage/integration1.16.3-next.0、backstage/plugin-catalog-backend1.32.1-next.0等。另外backstage/integration1.16.3-next.0本身有一个值得注意的 Patch提交 9768992GitHub 的webhookSecret配置属性被标记为可选——因为创建 GitHub App 时并不强制要求webhookSecret。这意味着集成配置的必填项收窄降低了 GitHub App 场景下的配置门槛。新模块Slack 通知处理器notifications-backend-module-slackbackstage/plugin-notifications-backend-module-slack0.1.0-next.0是本次版本首次发布的模块提交 552170d为 notifications 插件增加了一个Slack NotificationProcessor支持把 Backstage 通知通过 Slack 私信DM或频道消息发送出去。处理器在通知架构中的位置notifications 插件通过处理器Processor来扩展通知投递渠道。SlackNotificationProcessor实现了通知节点定义的NotificationProcessor接口注册到notificationsProcessingExtensionPoint之后会在通知发送流程的适当时机被调用详见模块装配代码 module.ts。配置项全解析配置位于app-config.yaml的notifications.processors.slack下是一个数组可以配置多个 Slack 工作区/机器人实例。完整的 Schema 定义见 config.d.ts参数说明如下配置项类型必填默认值说明tokenstring是—Slack Bot Token通常以xoxb-开头属于敏感配置visibility secretbroadcastChannelsstring[]否—广播通知的接收方可为 Slack 用户 ID、用户邮箱、频道名或频道 IDchat.postMessage接受的任意标识。已标记为 deprecated建议改用broadcastRoutesusernamestring否—通知显示的发送者名称broadcastRoutes对象数组否—基于 origin 和/或 topic 的广播路由按顺序求值、首个匹配生效见下文concurrencyLimitnumber否10每个后端实例的 Slack 通知并发上限throttleIntervalHumanDuration / string否1 分钟每个后端实例的 Slack 通知节流间隔broadcastRoutes中每个路由包含三个字段origin要匹配的来源例如plugin:catalog、external:my-servicetopic要匹配的主题例如entity-updated、alertschannel发送目标可为单个字符串或字符串数组频道 ID、频道名或用户 ID。路由的匹配优先级实现在 SlackNotificationProcessor.ts 的getBroadcastDestinations中origin topic 同时匹配最具体仅 origin 匹配仅 topic 匹配兜底回退到旧的broadcastChannels。配置示例notifications: processors: slack: - token: ${SLACK_BOT_TOKEN} username: Backstage Bot concurrencyLimit: 10 throttleInterval: minutes: 1 broadcastRoutes: - origin: plugin:scaffolder topic: task-completed channel: [C1234567890, #builds] - origin: external:monitoring channel: #alerts目标解析注解与邮箱回退处理器如何决定把通知发给哪个 Slack 目标核心是实体注解slack.com/bot-notify常量定义见 constants.ts。该注解的值可以是chat.postMessage接受的任意目标用户 ID如U12345678频道 ID如C12345678私信 ID如D12345678群组 ID如S12345678也支持邮箱地址或频道名但官方建议优先使用 ID。解析逻辑resolveSlackId优先读取实体的slack.com/bot-notify注解若实体是 User 且没有注解则通过其spec.profile.email调用 Slackusers.lookupByEmail反查 Slack ID均未命中则跳过该实体并记录 debug/error 日志。处理器还支持在通知文本中把形如user:default/billy的用户实体引用替换为 Slack 提及U12345678replaceUserRefsWithSlackIds并且通过 DataLoader 对实体查询做了批处理maxBatchSize: 100与 10 分钟缓存。更新语义scope 匹配与消息时间戳Slack 处理器对通知更新notification update有专门处理当一条通知携带origin和scope时处理器会在slack_message_timestamps表中记录已发送消息的时间戳ts。后续若同一originscope的通知发生更新会调用chat.update原地更新已有的 Slack 消息而不是再发一条新消息。这依赖一次数据库迁移见 module.ts 中的迁移逻辑并通过内置调度任务每 24 小时清理超过 24 小时保留期的旧时间戳记录。性能保护与可观测性模块内置了p-throttle节流concurrencyLimitthrottleInterval防止大批量接收用户的通知把系统阻塞三个 Prometheus 计数器指标notifications.processors.slack.sent.count发送成功数、notifications.processors.slack.error.count失败数、notifications.processors.slack.update.count通过 scope 匹配更新的消息数。扩展点自定义 Block Kit 渲染模块还暴露了一个扩展点notificationsSlackBlockKitExtensionPoint定义见 extensions.ts允许通过setBlockKitRenderer注册自定义渲染函数把NotificationPayload渲染为 Slack Block Kit 的KnownBlock[]从而定制消息的展示形式。扩展点只允许注册一次重复注册会抛错。值得关注的修复与其他更新本次预发布还包含若干功能性修复core-components5d7bad4修复了AlertDisplay中错误提示有更早的消息可用实为更新的消息的文案问题catalog-backend-module-bitbucket-cloud146e41b修复了事件驱动发现event-based discovery中导致对 Bitbucket Cloud 发起不必要 API 调用的问题catalog-import5b9514f因react-hook-form移除了UnpackNestedValue类型该插件改为自行导出该类型以保持兼容同时为Register an existing component文本补充了翻译f1d9a64scaffolder-backend-module-gitlab003dc15gitlab:group:ensureExistsaction 的path字段现在支持多段字符串如group/subgrouptechdocs-module-addons-contrib9c12a76修复ReportIssueaddon 在不支持的仓库类型下的渲染问题并改进了 Shadow DOM 内的事件处理techdocs-react0e9f7fe修复新前端系统下因多个 addons 数据附加导致 Catalog 实体文档页无法加载的问题auth-backend-module-bitbucket-provider5d10f99为 Bitbucket Cloud 启用了 scope 持久化integration-react同时为 Bitbucket Cloud 增加了projectscopekubernetesb877e46Kubernetes Tab 新增新前端系统过滤器使用isKubernetesAvailable控制可见性notifications-backend9a6080e允许对通知发送做节流避免海量接收用户时阻塞系统canonf7cb538 / 5e80f0b布局组件 prop 提取逻辑的内部重构与Icon组件类型修复。升级建议与验证清单由于这是预发布版本升级前请务必明确你的目标若需要验证上述新能力可在测试环境使用 Upgrade Helperchangelog 顶部提供的工具目标版本1.38.0-next.1生成升级指引若在生产环境建议等待 v1.38.0 正式版发布。重点检查以下三点GitHub 分支名扫描filters.branch配置移除所有含/的分支名否则后端可能无法启动Bitbucket Server 事件链路若你已经在用 Bitbucket Server 的 Catalog 模块确认是否要启用事件驱动的增量同步并按上文安装新增的 events 模块与配置 WebhookSlack 通知若希望启用 Slack 投递按notifications.processors.slack配置token等参数并确认实体注解slack.com/bot-notify或用户邮箱已就绪。如需深入了解相关模块的配置与实现可继续阅读仓库中的 processors.mdnotifications 处理器文档、events-backend-module-bitbucket-server 的 README 以及上文引用的源码文件。【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
