DevOps运维IaC【免费下载链接】chefChef Infra, a powerful automation platform that transforms infrastructure into code automating how infrastructure is configured, deployed and managed across any environment, at any scale项目地址https://gitcode.com/gh_mirrors/ch/chef点击查看免费下载在 Chef Infrachef/chef仓库的 CI 体系中Pull Request 测试只覆盖代码改动是否安全而真正的 Omnibus 打包与跨平台验证发生在合并之后。本篇技术指南围绕 docs/dev/how_to/running_adhoc_builds.md 展开讲解 Chef 工程师如何借助 Buildkite 的 ad hoc临时构建在不合并代码的情况下对任意分支执行与合并后完全相同的打包与测试路径从而提前发现影响包制作、影响依赖交付的复杂改动。读完本文你将掌握 ad hoc 构建的触发原理、操作步骤、底层管线脚本与平台矩阵以及产物下载方式。为什么只在 PR 上跑测试还不够Chef Infra Client 的测试体系分为两层每一层都在逐步提升开发者对改动安全性的信心Pull Request 测试第一道防线发生在 GitHub 的 PR 层面追求速度并受限于 GitHub 与公共 CI 实例的约束。它的目标是快速反馈代码本身有没有问题。构建测试合并后发生在代码合并之后会为所有受支持的平台制作安装包package并使用这些安装包执行 RSpec 测试。关键点在于这些 RSpec 测试是在包内部执行的测试针对的是真正交付给客户的依赖组合。因此当你的改动涉及包package本身——例如修改了打包脚本、依赖版本、平台适配逻辑——仅靠 PR 测试无法确认最终交付物是否可用。此时就应该运行一次 ad hoc Buildkite 构建ad hoc 构建走的是与合并后完全相同的路径唯一的区别是不需要真的合并代码。从仓库的 CI 文档 docs/dev/ci/README.md 可以看到Chef 的管线体系分为三类verifyPR 验证、validate/release合并后发布与validate/adhoc临时验证。其中 ad hoc 管线只保留 omnibus 构建与测试步骤是 verify 管线的一个子集专门用于在合并前验证小众平台esoteric platforms或特定平台的打包是否成功。Ad Hoc 管线的命名与创建机制Ad hoc Buildkite 构建可以由有权访问私有 Buildkite 账户的 Chef 员工针对chef/chefGitHub 仓库中的任意分支发起。每个分支的 ad hoc 管线并非手工维护而是由 Expeditor 依据配置文件自动创建。原文档中提到的 Expeditorconfig.yml在仓库中的实际位置是 .expeditor/config.yml其中pipelines段明确声明了validate/adhoc管线pipelines: - verify: public: true env: - IGNORE_ARTIFACTORY_RUBY_PROXY: true - validate/release: description: Validate release and promote Habitat package definition: .expeditor/verify.release.pipeline.yml - validate/adhoc: definition: .expeditor/verify.adhoc.pipeline.yml env: - ADHOC: true这些管线遵循统一的命名规范典型的 ad hoc 管线名slug为分支Ad Hoc 管线 slugmainchef/chef-main-validate-adhocChef 16维护分支chef/chef-chef-16-omnibus-adhoc值得注意的细节无论main还是chef-16这样的维护分支管线命名中都包含分支名这正是每个分支都有独立 ad hoc 管线这一机制的直接体现——管线是随分支配置自动生成与销毁的。启动一次 Ad Hoc 构建UI 操作在对应分支的 ad hoc 管线页面中操作步骤如下点击页面右上角的New Build新建构建填写要在 Buildkite UI 中展示的message构建说明信息指定要构建的commit提交哈希指定branch分支名。提交后Buildkite 会按该分支的管线定义拉取对应提交执行完整的 omnibus 构建与测试流程。除 UI 之外配置了 Buildkite CLI 的开发者还可以用bk build create命令触发例如 CI 文档中给出的bk build create --pipelinechef/chef-main-validate-adhoc下载构建产物构建完成后即可从 Buildkite 的构建详情页下载产物。产物被上传到Buildkite Artifacts存储。在管线中的验证步骤正是通过buildkite-agent artifact download下载这些产物再执行测试的例如 .expeditor/scripts/validate_adhoc_build.sh 中的片段export PKG_ARTIFACT$(buildkite-agent meta-data get $artifact_key) buildkite-agent artifact download $PKG_ARTIFACT .底层机制动态管线与平台矩阵当前 Chef 的管线已从Expeditor 生成的静态配置迁移为仓库内的动态管线脚本目的是让管线配置归属社区可见、可改的仓库源码而不是外部私有工具。Ad Hoc 相关的关键脚本都在 .buildkite 目录下文件职责.buildkite/validate.adhoc.pipeline.sh安装 Ruby 并调用 Ruby 脚本生成 ad hoc 管线 YAML再通过buildkite-agent pipeline upload上传.buildkite/validate-adhoc.rb以 Ruby 生成 ad hoc 管线的全部步骤构建 Habitat 包 各平台验证.buildkite/verify.pipeline.shverify 管线PR/合并后的动态生成脚本.buildkite/hooks/pre-command解析 .buildkite-platform.json注入工具版本与密钥Ad Hoc 的生成流程是.buildkite/validate.adhoc.pipeline.sh从 ruby-lang 缓存站点编译安装指定版本 Ruby然后执行/tmp/ruby-3.4.2-install/bin/ruby .buildkite/validate-adhoc.rb pipeline-config.yaml buildkite-agent pipeline upload pipeline-config.yamlvalidate-adhoc.rb中维护了完整的验证平台矩阵源码中的targets数组以平台:队列的格式定义targets [ amazon-2:centos-7, centos-7:centos-7, rhel-9:rhel-9, debian-9:debian-9, debian-10:debian-9, debian-11:debian-9, ubuntu-2004:ubuntu-2004, ubuntu-2204:ubuntu-2204, rocky-8:rocky-8, rocky-9:rocky-9, amazon-2023:amazon-2023 ]此外还通过arm_targets、win_targetswindows-2019/2022/2025、mac_targetsmacos-arm64扩展出 ARM、Windows 与 macOS 目标最终将这些目标拼接进管线步骤。每个步骤会选择对应队列如default-privileged、default-privileged-aarch64、default-windows-2019-privileged使用chefes/omnibus-toolchain-平台:OMNIBUS_TOOLCHAIN_VERSION作为 docker 镜像执行 .expeditor/scripts/validate_adhoc_build.shWindows 对应.ps1版本完成构建验证。当管线 slug 匹配chef-chef-main-validate-(adhoc|release)时脚本还会在验证步骤前插入四个 Habitat 包构建步骤x86_64-linux、aarch64-linux、windows、macOS并紧接一个wait步骤保证所有平台包构建完成后再统一验证。平台矩阵背后的构建测试细节从 docs/dev/ci/README.md 可以梳理出完整的能力边界Docker 容器平台verify、validate/adhoc、validate/release 均参与amazon-2、centos-6/7/8、rhel-9、debian-9/10/11、ubuntu-1604/1804/2004/2204、sles-15、windows-2019 等小众平台Esoteric仅 validate/adhoc 与 validate/release 参与aix-7.x-powerpc、el-7-ppc64/ppc64le/s390x、el-8-s390x、freebsd-12/13-amd64、mac_os_x 各版本x86_64 与 arm64、solaris2-5.11-i386/sparc、sles-12/15-s390x 等。文档明确提示小众平台资源有限除非使用 adhoc 管线否则不会在 PR 上测试——这正是 ad hoc 构建存在的核心价值之一容器平台采用 clean-room 环境每个构建互不污染且更易于本地调试与新增平台支持。如果只想构建/测试部分平台可以使用OMNIBUS_FILTER环境变量过滤平台子集这一能力被动态管线完整支持。另外工具链版本并非写死在脚本中而是集中在仓库根目录的 .buildkite-platform.json{ chef_foundation: 3.2.16, omnibus_toolchain: 3.0.39, ruby_version: 3.4.2, bundle_version: 2.6.9 }.buildkite/hooks/pre-command 会在任务执行前解析该文件并导出CHEF_FOUNDATION_VERSION、OMNIBUS_TOOLCHAIN_VERSION、RUBY_VERSION等环境变量同时完成git fetch origin main与非 main 分支的rebase 到最新 main、注入HAB_AUTH_TOKEN等密钥工作。这种工具版本入库、随源码复现构建的设计保证了 ad hoc 构建与正式构建使用完全一致的依赖环境。与 verify 管线的对比ad hoc 到底少了什么对照 docs/dev/ci/README.md 中 verify 管线的完整流程可以清晰看到 ad hoc 管线的取舍pre-commandhook 解析.buildkite-platform.json并注入版本与密钥两者共有upload 步骤上传动态生成的管线 YAML两者共有单元/功能/集成测试verify 有adhoc 无Omnibus 构建与测试两者共有adhoc 的主体Habitat 包构建与测试两者共有小众平台构建、Artifactory 构建记录创建、promote 到 current 通道仅 validate/release 有。也就是说ad hoc 管线本质上就是verify 管线去掉测试步骤、只留打包验证让开发者在合并前以最小的代价确认我的分支在支持的平台上都能打出包、且包内的 RSpec 测试能通过。常见问题仓库 CI 文档 FAQ 摘要为什么部分平台用 Docker 容器构建测试容器提供每个构建独立的 clean-room 环境也让新增平台支持更容易代价是管线需要同时管理两种计算形态。为什么要引入 chef-foundation避免每次发布都重新编译运行时依赖加快构建速度也让升级 Ruby 等运行时依赖更简单。旧的 adhoc/release 管线为什么还在出于历史目的保留一旦新动态管线在 chef 16/17 等分支回填并稳定后即可移除从 .expeditor/config.yml 中删除对应配置会自动在 Buildkite 中删除管线。小结Ad Hoc Buildkite 构建是 Chef Infra 开发流程中连接PR 快速验证与合并后全平台打包验证的关键桥梁。它的使用边界非常清晰当改动触及包制作、依赖交付或多平台构建时在合并前触发一次 ad hoc 构建即可复用合并后的完整打包路径。若你是 Chef 组织内拥有私有 Buildkite 权限的开发者只需在对应分支的-validate-adhoc管线页面点击 New Build、填写 message/commit/branch 三步就能获得覆盖容器平台与 esoteric 平台的打包验证结果其底层由 .buildkite/validate-adhoc.rb 动态生成管线、由 .expeditor/scripts/validate_adhoc_build.sh 驱动构建验证所有版本参数都收敛在 .buildkite-platform.json 中可复现、可审计。赞分享DevOps运维IaC【免费下载链接】chefChef Infra, a powerful automation platform that transforms infrastructure into code automating how infrastructure is configured, deployed and managed across any environment, at any scale项目地址https://gitcode.com/gh_mirrors/ch/chef点击查看免费下载相关推荐Chef Infra 终极指南如何通过Train集成实现跨平台远程执行Chef Infra 是一款功能强大的自动化运维工具而它与Train的深度集成为跨平台远程执行带来了革命性的便利。作为Chef的核心组件Train集成使得用DevOps运维IaCSlate V2 Headless Core 完成计划在不合并包拆分的前提下证明纯非 React 组合能力Slate V2 Headless Core 完成计划在不合并包拆分的前提下证明纯非 React 组合能力 导读 本文围绕 plate 仓库中 Slate V前端富文本UI组件如何在合并前测试 OpenToonz 的 Pull RequestAppVeyor 与 GitHub Actions 构建产物下载与验证指南如何在合并前测试 OpenToonz 的 Pull RequestAppVeyor 与 GitHub Actions 构建产物下载与验证指南 本篇指南面向希望桌面应用图形学上一篇TwitchPotPlayer终极使用指南在PotPlayer中完美播放Twitch直播下一篇skresnet18.ra_in1k性能优化提升图像分类准确率的3个关键技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
