openSUSE:发布团队流程
工具/仓库
Factory维护任务
我们从事各种领域的工作，以保持Factory的运行，并发布和安装ISO镜像。
提交请求的检查
我们监督 队列 并批准Factory仓库的新更新。
目前已经设置了自动化来完成一些任务
- 自动从开发项目提交更改到Factory（obs-autosubmit） FIXME：应该使用适当的锁定机制，而不是文件锁定
- 提交新的cpan包
- 验证提交的构建/安装完整性（repo-checker）
- factoryauto脚本
这些任务目前（2013-10-16）在opensuseqa.suse.de:2222的screen会话中以root身份处理
- 如果此会话未运行，则需要重新启动它。
- repo-checker部分应该被监控，以关闭仍处于“审核”阶段的失败的SR。
- 所有cron作业必须正常工作（在所有用户下）；特别是 */10 * * * * /abuild/home_package-lists/update-lists.sh脚本 FIXME：脚本应该使用适当的锁定机制，而不是文件锁定
如果repo-checker对某些包失败，并且您不想强制接受它，可以直接在机器上停止repo-checker的检查，并调用以下命令 osc check_repo --skip <SR#>，然后恢复队列。
如果请求相关（例如，应该一起验证安装状态），则应使用osc组功能，以确保repo-checker可以完成其工作
- osc group 是factory-auto仓库中提供的osc扩展脚本，使用起来非常简单。目前唯一的问题是您不能一次性批准请求，而是逐个提交批准。
在所有流程完成后，SR状态会更改为“新建”，我们应该在OBS的 状态监控器 显示没有大的负载时，将其批准到仓库中。大型重建应该计划在周五进行，以便在周末构建。
如果包未正确自动审核（例如，虽然应该通过却失败），则可以无论如何接受SR，但应避免这种情况，并应修复工具。
当提交被接受到Factory时，包会被重建，然后Factory:Rebuild项目中的所有反向依赖项会被重建。当此项目完成其任务后，仓库将被重新发布，并可供最终用户使用。
确保Factory的健康
Factory健康状况的验证可以在两个方面进行说明。确保一切都构建成功，并且所有包都可以解析，以及验证安装的系统是否实际上可用。
包验证在两个方面进行
除了这两个方面，我们还会通过邮件向维护者发送有关其包的报告，该报告针对他们的需求进行了个性化设置，仅列出他们参与的包。此脚本存储在 github 上，并使用coolo的邮件身份发送公告。
运行时验证也是两个阶段的过程
- openQA 测试，以查看至少基本功能是否正常工作
- 在我们的用户（以及我们自己，因为Factory的开发是从Factory完成的）上进行实时测试
发布和维护ISO发布版
生成用于发布/快照的ISO是一个相当复杂的过程。
- 所有构建必须完成，并且仓库状态必须在 正常树 上（即所有槽都标有“truck”图标）。这也会构建用于安装过程的镜像包，因为它们是在所有其他包构建之后构建的。
- Live 树必须启用，并且所有包都已构建+发布。 Live 包由packagelists机器上的cron作业更新，该机器更新 gitorious仓库，从而使用新的列表更新 Live 包。下一步再次只有在所有包再次发布后才能进行。
- 所有 产品 必须成功，才能提供所有必需的ISO镜像。
- Autobuild团队需要手动签名ISO并将其分发到 镜像。
任务的当前问题
- 更新包会导致生成多个ISO，因为Live会更新，所以所有产品都会重建，从而生成新的镜像，这需要新的Live更新。我的检查表明，一个包的更新会生成4个新的ISO构建（例如，Build001到Build004）。
- 我们没有简单的方法将包放入ISO，而是通过cron中的autobot来解决这个问题（以及手动编辑以适应DVD/CD，无论我们达成一致）。
- 签名和镜像分发应该自动化，以避免滥用autobuild团队。