首页 / 资讯中心 / 文章详情

BigBlueButton 构建与打包系统全解析:基于 GitLab CI 的开源 deb 包流水线

BigBlueButton 构建与打包系统全解析:基于 GitLab CI 的开源 deb 包流水线 ★ FEATURED ARTICLE
教育音视频后端前端【免费下载链接】bigbluebuttonA complete web conferencing system for virtual classes and more!项目地址https://gitcode.com/gh_mirrors/bi/bigbluebutton点击查看免费下载BigBlueButton 仓库中的build/目录承载了一套完整的开源构建与打包系统它以 GitLab CI 为流水线骨架将 BigBlueButton 的二十余个组件HTML5 客户端、akka 应用、GraphQL 服务、录制回放引擎等编译为 Debian 软件包并通过分支级 deb 仓库实现每分支一仓库的持续交付。本文以 build/README.md 为主线结合.gitlab-ci.yml与各构建脚本的源码实现完整讲解本地打包、CI 四阶段流水线、版本号规则、包模板机制与元包依赖管理帮助读者既能在本机快速产出 deb 包也能理解并二次开发这套 CI 构建体系。构建系统概览从私有 Jenkins 到开源 GitLab CIbuild/目录是 BigBlueButton 打包脚本的集中地README 明确指出它服务于新的开源 GitLab-CI 构建系统用于取代旧的非公开 Jenkins 流程。旧系统中的构建脚本被迁移到了packages-template/目录因此其中部分脚本仍保留着待优化/待清理的痕迹。整个构建系统的核心资产包括.gitlab-ci.yml位于仓库根目录的 CI 流水线定义声明了阶段、Docker 镜像与各组件构建任务build/setup.sh本地构建的入口脚本负责拉起 Docker 容器执行打包build/setup-inside-docker.sh容器内执行的真正打包逻辑CI 与本地共用build/change_detection.shCI 第一阶段判断哪些包可复用历史构建产物build/get_external_dependencies.sh拉取仓库外的第三方组件源码build/push_packages.sh将构建产物上传到 deb 仓库服务器build/package-names.inc.shdeb 包名到仓库源码目录的映射表build/packages-template/每个软件包的打包模板安装/卸载脚本、systemd 单元、nginx 配置等。在本地构建软件包前置条件README 明确要求本机必须安装 Docker。所有打包动作最终都在 Docker 容器内完成这样既保证了构建环境的可复现性也避免污染宿主机。第一步拉取外部依赖部分 BigBlueButton 组件的源码不在本仓库内如 freeswitch、bbb-pads、bbb-playback 等而是以占位符脚本的形式存在例如仓库根目录的 bbb-etherpad.placeholder.sh、freeswitch.placeholder.sh。构建前需要先执行./build/get_external_dependencies.sh该脚本的源码逻辑build/get_external_dependencies.sh非常巧妙它并不硬编码依赖清单而是用 Python 解析.gitlab-ci.yml中get_external_dependencies阶段的artifacts.paths再并行执行每个依赖对应的依赖名.placeholder.sh脚本下载源码从而避免同一份清单维护两处。README 也提到这些依赖未来可以迁移为 git submodule只是旧 CI 尚未退役前这样做会破坏兼容因此暂时保留占位符方案。第二步执行构建在仓库根目录运行例如构建bbb-html5包./build/setup.sh bbb-html5构建完成后生成的.deb文件位于仓库的artifacts/子目录下。bbb-html5包对应的源码目录是bigbluebutton-html5映射关系见 build/package-names.inc.sh。setup.sh 内部做了什么build/setup.sh 的源码揭示了本地构建的完整细节读取 CI 镜像用 Python 从.gitlab-ci.yml的default.image字段读取构建用 Docker 镜像保证本地与 CI 使用完全一致的构建环境。计算版本标识本地构建时GIT_REV取当前 HEAD 的前 10 位哈希并加local-build-前缀COMMIT_DATE取最近一次提交的时间戳格式%Y%m%dT%H%M%S。支持强制版本环境变量FORCE_GIT_REV与FORCE_COMMIT_DATE可以覆盖上述自动计算值。脚本注释说明这是为GitHub Actions 缓存历史包准备的——置为0即可让包版本始终不变。镜像拉取重试针对 Docker Hub 的toomanyrequests拉取速率受限错误脚本内置最多 5 次重试每次等待 300 秒5 分钟。容器挂载与信号处理容器以--detach方式启动并通过--cidfile记录容器 ID宿主机脚本随后docker attach附加到容器输出同时注册SIGINT/SIGTERM陷阱Ctrl-C 时自动docker kill容器避免构建残留。目录挂载仓库根目录绑定挂载到容器内/mntartifacts/绑定挂载到/artifacts容器内执行setup-inside-docker.sh 包名完成打包。容器内打包setup-inside-docker.shbuild/setup-inside-docker.sh 是 CI 与本地共用的核心打包脚本CI 模式跳过检查非本地构建LOCAL_BUILD ! 1时会先 greppackages_to_skip.txt若当前包可复用历史产物则直接退出缓存目录在仓库根目录创建cache/.gradle、.grails、.ivy2、.m2并符号链接到容器的/root下实现跨构建的依赖缓存复用对应.gitlab-ci.yml中cache段的cache/.gradle组装构建目录把packages-template/包名/下的模板文件复制到/tmp/build/包名_版本_发行版/再按package-names.inc.sh的映射把源码目录复制进去对于多源码目录的包如bbb-apps-akka对应akka-bbb-apps bbb-common-message两个目录会逐个复制注入全局 fpm 参数把 build/opts-global.sh 复制进构建目录其内容为--vendor BigBlueButton -m ffdixonbigbluebutton.org --url https://bigbluebutton.org/即所有包的 vendor/维护者/主页元数据拼接生命周期脚本将 build/deb-helper.sh 与各包的before-install.sh、after-install.sh、after-remove.sh、before-remove.sh拼接成最终脚本deb-helper.sh提供startService/stopService/reloadService/restartService/addUser/addGroup等通用函数优先使用 systemd回退到update-rc.d/chkconfig执行打包在构建目录内运行build.sh产物*.deb复制到/artifacts。版本号规则版本号在 build/setup-inside-docker.sh 中计算来源是 bigbluebutton-config/bigbluebutton-release 文件格式形如BBB_VERSION3.0.x构建类型版本格式示例说明release2:3.0.0-1由 EPOCH默认 2、版本号、BUILD_NUMBER默认 1组成devel2:3.0.0~alpha420260924T045421-git.abcdef版本号 ~附加标识 提交时间 -git. 提交哈希其中BUILD_NUMBER和EPOCH均可用环境变量覆盖VERSION_ADDON如alpha4同样取自 release 文件目标发行版当前固定为jammyDISTROjammy。通过 GitLab CI 构建CI 流水线由仓库根目录的 .gitlab-ci.yml 定义构建过程分为四个阶段。README 中附有官方流程示意图图中展示的完整链路为开发者向官方仓库推送分支 → 通过 GitLab CI for GitHub Actions 或 GitLab CI/CD for external repositories 两种方式触发流水线 → 依次执行变更检测change detection、获取外部依赖get external dependencies、并行构建build、包推送push packages四个阶段 → 最终上传到每分支一个独立 deb 仓库的 CI 仓库服务器服务器可响应apt update apt dist-upgrade将系统升级到该分支的最新提交版本。阶段一变更检测change detection对应 build/change_detection.sh。该阶段的目标是找出哪些包可以复用历史构建从而大幅节省构建时间遍历DEBNAME_TO_SOURCEDIR映射表中的每个包bigbluebutton元包除外它永远重建用git log找到最近一次改动该包源码、其包模板及 CI 相关文件的提交LAST_CHANGE再把LAST_CHANGE之后的所有提交哈希各取前 10 位作为候选可用版本将形如{bbb-html5: [abc123def4, fedcba9876, ...]}的 JSON 通过 curl 发送到仓库服务器的get_compatible_packages.py接口使用PACKAGES_UPLOAD_AUTHENTICATION认证服务器返回哪些版本已有可用构建结果写入仓库根目录的packages_to_skip.txt。packages_to_skip.txt会被作为 GitLab artifacts 传递给后续阶段构建阶段的各 job 据此跳过无需重建的包bigbluebutton元包构建据其为依赖钉住历史版本push_packages阶段则把可复用包的文件名一并上报服务器。阶段二获取外部依赖get external dependencies对应get_external_dependenciesjob脚本为 build/get_external_dependencies.sh。它并行执行各.placeholder.sh占位符脚本拉取 bbb-etherpad、bbb-webhooks、bbb-webrtc-sfu、bbb-webrtc-recorder、freeswitch、bbb-pads、bbb-playback、bbb-transcription-controller 等外部仓库源码产物以 artifacts 形式保留expire_in: 1h 30min。阶段三并行构建build.gitlab-ci.yml中定义了bbb-apps-akka-build、bbb-config-build、bbb-html5-build、bbb-graphql-middleware-build、bbb-web-build、bbb-livekit、bigbluebutton-build等二十余个构建 job全部extends自模板 job.build_job产物为artifacts/*.deb缓存 key 为分支名。每个 job 的核心命令都是build/setup-inside-docker.sh 包名与本地构建共用同一套打包逻辑。被packages_to_skip.txt列中的包直接跳过重建。此外该阶段还会创建bigbluebutton元包。其构建脚本 build/packages-template/bigbluebutton/build.sh 展示了元包的依赖生成机制遍历核心包清单bbb-apps-akka、bbb-config、bbb-html5、bbb-web 等 22 个包对每个包若其在packages_to_skip.txt中则取其历史版本号否则用当前提交对应的版本号生成Depends: bbb-html5 ( 2:3.0.0~...-git.abcdef), bbb-web ( 2:...), ...形式的精确版本钉定依赖列表通过equivs-build control生成元包Package: bigbluebuttonArchitecture: amd64Section: web。这意味着安装bigbluebutton元包即可一次性安装整套相互兼容的核心组件且各组件版本严格一致。阶段四上传软件包push packages对应 build/push_packages.sh该 job 使用resource_group: push_packages保证同一时刻只有一个推送任务执行避免并发冲突。其动作包括从packages_to_skip.txt提取可复用包文件名每行第二列组成逗号分隔的additional_package_files用 curl 的-F pkgs[]file逐个上传artifacts/*.deb同时提交branch${CI_COMMIT_BRANCH}分支名与gpg_passphrase${GPG_PASSPHRASE}用于仓库签名服务端ci-repo-upload/cgi-bin/incoming.py收到后会为该分支生成/更新对应的 deb 仓库把新上传的包与复用的历史包全部纳入该分支仓库。包模板与生命周期脚本机制build/packages-template/下每个子目录对应一个 deb 包README 指出这些模板源自旧 Jenkins 系统仍存在优化空间。以 build/packages-template/bbb-html5/ 为例模板通常包含before-install.sh/after-install.sh/before-remove.sh/after-remove.sh生命周期钩子会被拼上deb-helper.sh通用函数后执行*.servicesystemd 单元文件如 bbb-graphql-middleware.service 所在目录中的各类服务*.nginxNginx 站点配置片段opts-jammy.sh针对 jammy 发行版的 fpm 附加选项。这种模板 源码目录的分离设计让打包逻辑依赖、服务、权限、配置与源码本身解耦新增一个组件时只需添加模板目录并在package-names.inc.sh中登记映射即可。自定义构建镜像与扩展README 特别说明setup.sh默认会从远端拉取构建用 Docker 镜像即.gitlab-ci.yml中default.image声明的bigbluebutton/bbb-build:v3.0.x-release-...。如果你希望自行构建镜像获取该镜像对应的DockerfileREADME 指向的 docker-bbb-build 仓库中使用 Docker 的文本文件构建方式本地构建该镜像将.gitlab-ci.yml中的镜像地址改为本地镜像即可。此外若你在 GitHub Actions 上复用本套脚本可利用FORCE_GIT_REV0与FORCE_COMMIT_DATE0固定包版本配合缓存机制复用历史构建产物避免每次构建都产生全新版本号。总结BigBlueButton 的构建系统以 build/README.md 为纲、以.gitlab-ci.yml为流水线骨架通过setup.sh本地与setup-inside-docker.sh容器内共享同一打包核心配合change_detection.sh的变更感知跳过机制、占位符式外部依赖拉取、并行 deb 构建与分支级仓库推送形成了一套从源码到可安装 deb 包的完整持续交付链路。理解这套体系后无论是手动在本地打出某个组件的 deb 包还是为自维护的分支搭建专属包仓库都能直接复用仓库内已有的脚本与模板。赞分享教育音视频后端前端【免费下载链接】bigbluebuttonA complete web conferencing system for virtual classes and more!项目地址https://gitcode.com/gh_mirrors/bi/bigbluebutton点击查看免费下载相关推荐从源码构建 KeyDB DEB 包pkg/deb 打包体系全解析从源码构建 KeyDB DEB 包pkg/deb 打包体系全解析 本指南围绕 KeyDB 仓库 pkg/README.md https://link.gitc数据库KV存储缓存数据存储RenderDoc 打包构建系统全解析基于 build.sh 的跨平台发布流水线实战指南RenderDoc 打包构建系统全解析基于 build.sh 的跨平台发布流水线实战指南 本文聚焦 RenderDoc 仓库中负责打包发布构建的脚本体系开发工具调试器图形学GPUcuDF Java JAR 构建与发布流水线基于 ci-wheel 容器的一站式打包实践cuDF Java JAR 构建与发布流水线基于 ci wheel 容器的一站式打包实践 cuDF 的 Java API 依赖一个内嵌静态 libcudf 的数据分析数据工程机器学习上一篇Keyviz 无障碍功能路线图未来改进计划下一篇react-pdf-js源码探秘深入理解PDF文档加载与页面渲染机制创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
阅读完成 · 觉得有帮助?
咨询建站