catalog-release

用途：把 Pega Dev Components 目录中的组件发布到基于 GitHub Pages 的目录站点，适用于用户提出 publish、release、deploy 某组件（如 Blueprint 或 CDH）的场景。\n\n主要能力：支持 Blueprint（包 platform-blueprint-component，脚本 ./scripts/blueprint_release.sh）与 CDH（包 cdh-blueprint-component，脚本 ./scripts/cdh_release.sh）。发布脚本会校验输入与 manifest 语法、从 Artifactory 下载各平台制品、更新 index.json（版本、日期、URL 的路径与文件名）、启动本地 HTTP 服务验证版本出现、创建发布分支、提交并推送，最后输出 PR URL。还提供 dry-run、验证发布、检查发布状态、拉取并合并 main 更新等流程。\n\n必要用法：先设置 export artifactory_key="your-artifactory-token"，在 pega-dev-components 仓库工作目录中执行，并准备工单号（格式 RLS-XXXXX）。发布命令形如 ./scripts/<component>_release.sh --dry-run <version> <work_item> <date>，确认后去掉 --dry-run 实际执行。发布后可用 source scripts/catalog_release_lib.sh 后执行 catalog_verify_render "$(pwd)" "<version>" 验证。脚本标志包括 --dry-run（预览）与 --no-commit（仅本地暂存）。PR 合并到 main 后由 GitHub Actions 自动部署到对应 GitHub Pages 地址。\n\n平台版本：Blueprint 支持 23.1.0、24.1.0、24.2.0、25.1.0、26.1.0；JAR 变体为 blueprint-<version>-bundle.jar（23.1.0、24.1.0、24.2.0）与 blueprint-<version>-bundle-jakarta.jar（25.1.0、26.1.0）。\n\n适用场景：需要按标准流程发布组件并生成待审核 PR 时。限制与注意：需具备 Artifactory token 与推送权限，工单号必填，发布前建议先 dry-run，完成后需验证，合并冲突通常出现在 index.json 并保留 HEAD 版本更新。发布方式、平台版本与限制均来自资料；收费与价格暂未提供。