使用 Buddy CI 构建、测试与部署 Jekyll 站点从 GUI 流水线到 buddy.yml 配置实战【免费下载链接】jekyll:globe_with_meridians: Jekyll is a blog-aware static site generator in Ruby项目地址: https://gitcode.com/gh_mirrors/je/jekyll本篇指南以 Jekyll 官方文档中的 Buddy 持续集成方案为核心讲解如何借助基于 Docker 的 CI 服务器 Buddy在 15-20 分钟内为 Jekyll 项目搭建推送即构建的自动化流水线覆盖 GUI 快速配置、YAML 声明式配置、产物部署与本地化部署等完整路径并深入 Jekyll 源码说明jekyll build在流水线中的真实执行行为。Buddy 是什么为什么适合 Jekyll 项目Buddy 是一款基于 Docker 的 CI持续集成服务器可以在 15-20 分钟内完成搭建用于构建、测试和部署 Jekyll 网站。它的核心优势在于多 Git 平台支持支持 GitHub、Bitbucket 与 GitLab 仓库灵活部署形态既可使用 Buddy 云端服务也可以安装到自有服务器on-premises免费起步可以搭建一个免费的构建环境来运行 Jekyll 项目的构建与测试。对于 Jekyll 这类纯静态生成的项目而言CI 的典型价值在于每次推送代码后自动执行jekyll build验证站点能否成功生成再进一步把生成的_site目录发布到 FTP/SFTP、对象存储等目标从而形成提交即发布的稳定工作流。1. 快速开始5 分钟跑通第一个流水线按照官方文档在 Buddy 云端完成 Jekyll 项目 CI 的初始化只需要四步访问 buddy.works 并使用 GitHub/Bitbucket 账号或邮箱登录选择你的 Git 提供商选中或推送你的 Jekyll 项目创建新的 pipeline流水线并将触发模式trigger mode设置为On every push每次推送触发添加并配置Jekyll action然后保存流水线。完成上述配置后Buddy 会在你向选定分支推送代码时自动执行构建任务无需人工干预。2. 工作原理Docker 镜像中的jekyll buildBuddy 流水线的核心机制非常直观每当你向选中分支推送代码Jekyll action就会在一个隔离的 Jekyll Docker 镜像jekyll/jekyll中运行jekyll build构建产物输出到容器的/filesystem目录。这一机制与 Jekyll 的 CLI 设计完全吻合。在本仓库中jekyll build命令由 exe/jekyll 入口调度、在 lib/jekyll/commands/build.rb 中实现命令解析后创建Jekyll::Site实例并调用process构建期间会打印Source与Destination路径默认输出目录为当前目录下的_site见 lib/jekyll/configuration.rb 中destination File.join(Dir.pwd, _site)的默认配置。完整的构建生命周期在 lib/jekyll/site.rb 的process方法中依次执行read → generate → render → cleanup → write。在 Buddy 流水线中/filesystem目录即相当于 Jekyll 默认的_site输出位置。构建完成后你可以将产物继续部署到FTP/SFTP以及各类IaaS 服务在流水线中追加自己的命令、安装额外软件包、挂载附加服务attach services甚至运行 Selenium 端到端测试在 Jekyll action 之后串联更多 action例如发送Slack 通知或通过SSH 脚本重启目标服务器。换句话说Buddy 把构建和发布解耦成流水线中的不同 actionJekyll action 只负责生成静态站点发布动作交给后续环节完成职责清晰、易于扩展。3. 用 YAML 声明式配置buddy.yml完整解析如果你更喜欢配置即代码configuration as code而非 GUI 操作可以把流水线写成buddy.yml放在仓库中一旦推送到目标分支Buddy 会自动据此创建包含 Jekyll action 的流水线。官方文档给出的完整示例为- pipeline: Build and Deploy Jekyll site trigger_mode: ON_EVERY_PUSH ref_name: master actions: - action: Execute: jekyll build type: BUILD docker_image_name: jekyll/jekyll docker_image_tag: latest execute_commands: - chown jekyll:jekyll $WORKING_DIR - jekyll build逐项说明各字段的含义与取值字段含义说明pipeline流水线名称例如Build and Deploy Jekyll site用于在 Buddy 界面中标识该流水线trigger_mode触发模式ON_EVERY_PUSH表示每次推送即触发也可按需改为其他触发策略ref_name监听的分支示例为master仅在推送到该分支时触发构建actionaction 显示名称在流水线图中展示的动作名typeaction 类型BUILD表示构建类 action在 Docker 容器中执行命令docker_image_name使用的 Docker 镜像jekyll/jekyll是 Jekyll 官方镜像内置了 Ruby、Jekyll 及其构建依赖docker_image_tag镜像标签示例用latest生产环境建议固定到具体版本以获得可复现的构建execute_commands容器内要执行的命令序列按顺序执行任一命令失败即判定构建失败示例中的两条命令值得留意chown jekyll:jekyll $WORKING_DIR将工作目录的所有者调整为jekyll用户。Jekyll 官方 Docker 镜像默认以非 root 的jekyll用户运行此命令可规避容器内目录权限不足导致的写入失败jekyll build执行站点构建生成静态站点产物。4. 从源码理解jekyll build的执行细节为了让流水线中的jekyll build稳定工作理解其底层行为很有帮助。查看本仓库源码可以发现几个关键事实默认输出目录是_site。lib/jekyll/configuration.rb 中将默认destination设为当前目录下的_site构建命令 lib/jekyll/commands/build.rb 会打印Source与Destination路径并统计耗时因此在 Buddy 构建日志中可以直接看到这两项信息便于排查路径问题。构建是一次完整的多阶段流水。lib/jekyll/site.rb 中Site#process依次执行reset → read → generate → render → cleanup → write读取源文件、运行生成器、渲染 Liquid/Markdown、清理目标目录、最终写入_site。这意味着任何一步出错如 Liquid 语法错误、插件异常都会导致jekyll build以非零状态退出Buddy 据此将构建标记为失败——这正是把能否成功构建当作 CI 第一道门槛的原理。Ruby 版本与依赖约束。根据 jekyll.gemspec本仓库要求 Ruby 2.7.0并依赖 kramdown、liquid、jekyll-sass-converter、rouge 等 gem。使用官方jekyll/jekyll镜像可免去自行安装 Ruby 环境的麻烦若选择自定义镜像则需自行保证 Ruby 版本与依赖满足要求。推荐用 Bundler 管理依赖。与仓库中其他 CI 指南如 CircleCI 指南、Travis CI 指南一致官方建议在项目根目录维护Gemfile声明 Jekyll 版本、插件与测试工具如html-proofer并提交Gemfile.lock然后在流水线中先执行bundle install再执行bundle exec jekyll build。Buddy 的execute_commands完全支持这种组合execute_commands: - chown jekyll:jekyll $WORKING_DIR - bundle install - bundle exec jekyll build5. 构建产物部署连接 FTP/SFTP 与云服务jekyll build完成后产物位于/filesystem目录等价于本地的_siteBuddy 流水线可以在后续 action 中将其推送到目标环境。官方文档明确支持的部署目标包括FTP/SFTP适合传统虚拟主机或自有服务器将静态文件同步到站点根目录即可上线IaaS 服务例如 AWS S3、对象存储等配合静态网站托管能力对外提供服务自定义扩展通过 SSH 脚本重启 Web 服务器如 Nginx或发送 Slack 通知告知团队发布结果。如果你的仓库中同时配置了baseurl站点的子路径前缀部署时需注意产物目录内的路径结构与线上 URL 的对应关系Jekyll 的url与baseurl配置项会共同影响生成链接这一点同样会在构建日志中体现。6. 本地化部署在自有服务器上运行 Buddy如果出于安全、合规或成本考虑不打算使用云端 CIBuddy 提供 self-hosted自托管版本可以安装在任何支持 Docker 的服务器上官方文档列举的典型场景包括Linux服务器Mac环境AWS EC2云主机DigitalOceanDropletMicrosoft Azure虚拟机。由于 Buddy 本身基于 Docker自托管时只需准备一台可运行 Docker 的机器再按其官方安装文档执行即可安装完成后流水线配置方式GUI 或buddy.yml与云端完全一致。7. 常见问题与后续优化建议QJekyll 官方镜像默认用户是什么为什么需要chownAjekyll/jekyll镜像出于安全考虑默认以jekyll用户运行而流水线挂载的工作目录可能归属 root导致jekyll build写_site时权限不足。官方示例中的chown jekyll:jekyll $WORKING_DIR正是为了消除这一隐患。Q能否只监听特定分支A可以。通过ref_name指定分支如masterBuddy 只在该分支的推送事件上触发流水线适合仅正式分支发布的部署策略。Q如何在构建失败时得到通知A在 Jekyll action 之后追加 Slack 等通知类 action 即可任何命令以非零状态退出都会让流水线失败从而触发通知。Q是否可以对构建产物做质量检查A可以。参照仓库中其他 CI 文档的做法可在execute_commands中追加bundle exec htmlproofer ./_site之类的检查命令详见 CircleCI 指南 与 Travis CI 指南 中关于 HTML Proofer 的用法在部署前验证链接与 HTML 有效性。8. 小结Buddy 为 Jekyll 项目提供了一条低门槛、可扩展的持续集成路径云端或自托管皆可GUI 与 YAML 两种配置方式并存jekyll build在官方 Docker 镜像中隔离执行产物统一输出到/filesystem再由流水线后续 action 完成测试、通知与部署。无论你从四步 GUI 配置起步还是直接把buddy.yml提交进仓库都能在十几分钟内为站点建立可靠的自动化发布流程。【免费下载链接】jekyll:globe_with_meridians: Jekyll is a blog-aware static site generator in Ruby项目地址: https://gitcode.com/gh_mirrors/je/jekyll创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 Buddy CI 构建、测试与部署 Jekyll 站点：从 GUI 流水线到 buddy.yml 配置实战
使用 Buddy CI 构建、测试与部署 Jekyll 站点从 GUI 流水线到 buddy.yml 配置实战【免费下载链接】jekyll:globe_with_meridians: Jekyll is a blog-aware static site generator in Ruby项目地址: https://gitcode.com/gh_mirrors/je/jekyll本篇指南以 Jekyll 官方文档中的 Buddy 持续集成方案为核心讲解如何借助基于 Docker 的 CI 服务器 Buddy在 15-20 分钟内为 Jekyll 项目搭建推送即构建的自动化流水线覆盖 GUI 快速配置、YAML 声明式配置、产物部署与本地化部署等完整路径并深入 Jekyll 源码说明jekyll build在流水线中的真实执行行为。Buddy 是什么为什么适合 Jekyll 项目Buddy 是一款基于 Docker 的 CI持续集成服务器可以在 15-20 分钟内完成搭建用于构建、测试和部署 Jekyll 网站。它的核心优势在于多 Git 平台支持支持 GitHub、Bitbucket 与 GitLab 仓库灵活部署形态既可使用 Buddy 云端服务也可以安装到自有服务器on-premises免费起步可以搭建一个免费的构建环境来运行 Jekyll 项目的构建与测试。对于 Jekyll 这类纯静态生成的项目而言CI 的典型价值在于每次推送代码后自动执行jekyll build验证站点能否成功生成再进一步把生成的_site目录发布到 FTP/SFTP、对象存储等目标从而形成提交即发布的稳定工作流。1. 快速开始5 分钟跑通第一个流水线按照官方文档在 Buddy 云端完成 Jekyll 项目 CI 的初始化只需要四步访问 buddy.works 并使用 GitHub/Bitbucket 账号或邮箱登录选择你的 Git 提供商选中或推送你的 Jekyll 项目创建新的 pipeline流水线并将触发模式trigger mode设置为On every push每次推送触发添加并配置Jekyll action然后保存流水线。完成上述配置后Buddy 会在你向选定分支推送代码时自动执行构建任务无需人工干预。2. 工作原理Docker 镜像中的jekyll buildBuddy 流水线的核心机制非常直观每当你向选中分支推送代码Jekyll action就会在一个隔离的 Jekyll Docker 镜像jekyll/jekyll中运行jekyll build构建产物输出到容器的/filesystem目录。这一机制与 Jekyll 的 CLI 设计完全吻合。在本仓库中jekyll build命令由 exe/jekyll 入口调度、在 lib/jekyll/commands/build.rb 中实现命令解析后创建Jekyll::Site实例并调用process构建期间会打印Source与Destination路径默认输出目录为当前目录下的_site见 lib/jekyll/configuration.rb 中destination File.join(Dir.pwd, _site)的默认配置。完整的构建生命周期在 lib/jekyll/site.rb 的process方法中依次执行read → generate → render → cleanup → write。在 Buddy 流水线中/filesystem目录即相当于 Jekyll 默认的_site输出位置。构建完成后你可以将产物继续部署到FTP/SFTP以及各类IaaS 服务在流水线中追加自己的命令、安装额外软件包、挂载附加服务attach services甚至运行 Selenium 端到端测试在 Jekyll action 之后串联更多 action例如发送Slack 通知或通过SSH 脚本重启目标服务器。换句话说Buddy 把构建和发布解耦成流水线中的不同 actionJekyll action 只负责生成静态站点发布动作交给后续环节完成职责清晰、易于扩展。3. 用 YAML 声明式配置buddy.yml完整解析如果你更喜欢配置即代码configuration as code而非 GUI 操作可以把流水线写成buddy.yml放在仓库中一旦推送到目标分支Buddy 会自动据此创建包含 Jekyll action 的流水线。官方文档给出的完整示例为- pipeline: Build and Deploy Jekyll site trigger_mode: ON_EVERY_PUSH ref_name: master actions: - action: Execute: jekyll build type: BUILD docker_image_name: jekyll/jekyll docker_image_tag: latest execute_commands: - chown jekyll:jekyll $WORKING_DIR - jekyll build逐项说明各字段的含义与取值字段含义说明pipeline流水线名称例如Build and Deploy Jekyll site用于在 Buddy 界面中标识该流水线trigger_mode触发模式ON_EVERY_PUSH表示每次推送即触发也可按需改为其他触发策略ref_name监听的分支示例为master仅在推送到该分支时触发构建actionaction 显示名称在流水线图中展示的动作名typeaction 类型BUILD表示构建类 action在 Docker 容器中执行命令docker_image_name使用的 Docker 镜像jekyll/jekyll是 Jekyll 官方镜像内置了 Ruby、Jekyll 及其构建依赖docker_image_tag镜像标签示例用latest生产环境建议固定到具体版本以获得可复现的构建execute_commands容器内要执行的命令序列按顺序执行任一命令失败即判定构建失败示例中的两条命令值得留意chown jekyll:jekyll $WORKING_DIR将工作目录的所有者调整为jekyll用户。Jekyll 官方 Docker 镜像默认以非 root 的jekyll用户运行此命令可规避容器内目录权限不足导致的写入失败jekyll build执行站点构建生成静态站点产物。4. 从源码理解jekyll build的执行细节为了让流水线中的jekyll build稳定工作理解其底层行为很有帮助。查看本仓库源码可以发现几个关键事实默认输出目录是_site。lib/jekyll/configuration.rb 中将默认destination设为当前目录下的_site构建命令 lib/jekyll/commands/build.rb 会打印Source与Destination路径并统计耗时因此在 Buddy 构建日志中可以直接看到这两项信息便于排查路径问题。构建是一次完整的多阶段流水。lib/jekyll/site.rb 中Site#process依次执行reset → read → generate → render → cleanup → write读取源文件、运行生成器、渲染 Liquid/Markdown、清理目标目录、最终写入_site。这意味着任何一步出错如 Liquid 语法错误、插件异常都会导致jekyll build以非零状态退出Buddy 据此将构建标记为失败——这正是把能否成功构建当作 CI 第一道门槛的原理。Ruby 版本与依赖约束。根据 jekyll.gemspec本仓库要求 Ruby 2.7.0并依赖 kramdown、liquid、jekyll-sass-converter、rouge 等 gem。使用官方jekyll/jekyll镜像可免去自行安装 Ruby 环境的麻烦若选择自定义镜像则需自行保证 Ruby 版本与依赖满足要求。推荐用 Bundler 管理依赖。与仓库中其他 CI 指南如 CircleCI 指南、Travis CI 指南一致官方建议在项目根目录维护Gemfile声明 Jekyll 版本、插件与测试工具如html-proofer并提交Gemfile.lock然后在流水线中先执行bundle install再执行bundle exec jekyll build。Buddy 的execute_commands完全支持这种组合execute_commands: - chown jekyll:jekyll $WORKING_DIR - bundle install - bundle exec jekyll build5. 构建产物部署连接 FTP/SFTP 与云服务jekyll build完成后产物位于/filesystem目录等价于本地的_siteBuddy 流水线可以在后续 action 中将其推送到目标环境。官方文档明确支持的部署目标包括FTP/SFTP适合传统虚拟主机或自有服务器将静态文件同步到站点根目录即可上线IaaS 服务例如 AWS S3、对象存储等配合静态网站托管能力对外提供服务自定义扩展通过 SSH 脚本重启 Web 服务器如 Nginx或发送 Slack 通知告知团队发布结果。如果你的仓库中同时配置了baseurl站点的子路径前缀部署时需注意产物目录内的路径结构与线上 URL 的对应关系Jekyll 的url与baseurl配置项会共同影响生成链接这一点同样会在构建日志中体现。6. 本地化部署在自有服务器上运行 Buddy如果出于安全、合规或成本考虑不打算使用云端 CIBuddy 提供 self-hosted自托管版本可以安装在任何支持 Docker 的服务器上官方文档列举的典型场景包括Linux服务器Mac环境AWS EC2云主机DigitalOceanDropletMicrosoft Azure虚拟机。由于 Buddy 本身基于 Docker自托管时只需准备一台可运行 Docker 的机器再按其官方安装文档执行即可安装完成后流水线配置方式GUI 或buddy.yml与云端完全一致。7. 常见问题与后续优化建议QJekyll 官方镜像默认用户是什么为什么需要chownAjekyll/jekyll镜像出于安全考虑默认以jekyll用户运行而流水线挂载的工作目录可能归属 root导致jekyll build写_site时权限不足。官方示例中的chown jekyll:jekyll $WORKING_DIR正是为了消除这一隐患。Q能否只监听特定分支A可以。通过ref_name指定分支如masterBuddy 只在该分支的推送事件上触发流水线适合仅正式分支发布的部署策略。Q如何在构建失败时得到通知A在 Jekyll action 之后追加 Slack 等通知类 action 即可任何命令以非零状态退出都会让流水线失败从而触发通知。Q是否可以对构建产物做质量检查A可以。参照仓库中其他 CI 文档的做法可在execute_commands中追加bundle exec htmlproofer ./_site之类的检查命令详见 CircleCI 指南 与 Travis CI 指南 中关于 HTML Proofer 的用法在部署前验证链接与 HTML 有效性。8. 小结Buddy 为 Jekyll 项目提供了一条低门槛、可扩展的持续集成路径云端或自托管皆可GUI 与 YAML 两种配置方式并存jekyll build在官方 Docker 镜像中隔离执行产物统一输出到/filesystem再由流水线后续 action 完成测试、通知与部署。无论你从四步 GUI 配置起步还是直接把buddy.yml提交进仓库都能在十几分钟内为站点建立可靠的自动化发布流程。【免费下载链接】jekyll:globe_with_meridians: Jekyll is a blog-aware static site generator in Ruby项目地址: https://gitcode.com/gh_mirrors/je/jekyll创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考