openSUSE:Build Service Concept GitSupport
关于在OBS中支持git后端的新的提案。
简介
提议的git后端增强了OBS当前非常基础的源代码控制，提供了一个最新的版本控制系统，其范围可以达到项目间、项目内、软件包间或软件包内。旧的osc客户端仅用于使用osc的git仓库的提案已被新的提案取代。旧方法不允许对源代码进行项目范围的管理。需要一个新的系统来将构建和版本控制在项目和软件包级别上粘合在一起，以实现这种新的方法。将引入类似于“构建仓库”的抽象概念，用于构建，在项目级别用于版本控制，称为“源代码仓库”。
熟悉git的用户如果想了解设计思路，可以直接查看“用例”和“测试”部分，而无需研究过多的功能或实现细节。该项目由用例和工作流需求驱动。
先前工作
2009年，有一个Google Summer of Code项目，旨在为构建服务创建一个git后端。该包含一些想法，但总体项目未能实现其目标。
另一个最近的项目产生了一个名为 [bsgit] 的工具。该工具可用于将现有的构建服务软件包导入git格式。生成的git仓库包含完整的修订历史记录，可以直接推送到未来的git后端。最重要的是，bsgit正确转换了源代码链接（这些链接可能基于源代码链接本身），并演示了如何在真正的版本控制系统之上实现源代码链接功能。（此外，该工具可以用作一个极简的构建服务客户端：提交到git仓库的更改可以“推回”到构建服务。当然，像bsgit这样的客户端解决方案无法克服现有后端的根本限制，例如其非分布式架构，并且在使用bsgit时会丢失当前后端无法存储的信息。）
作者在这里发表了一个关于git如何融入构建服务以及bsgit背后的想法的的演示文稿。
SCM
版本控制（也称为源代码管理或（源代码）管理）是对存储为计算机文件的文档、程序和其他信息的更改的管理。它最常用于软件开发中，在软件开发中，团队成员可能会更改相同的文件。更改通常由一个数字或字母代码标识，称为“修订号”、“修订级别”或简称“修订”。例如，初始文件集是“修订 1”。当进行第一次更改时，结果集是“修订 2”，依此类推。每个修订都与时间戳和进行更改的人相关联。可以比较、恢复和对于某些类型的文件，合并修订。较新的设计（如git）通常通过消除对所有开发人员必须访问的中央服务器的约束来支持分布式版本控制。
构建系统
构建系统从给定的源代码/源代码树生成一组二进制文件。必须满足依赖链才能成功构建。与SCM不同，SCM的目标是动态的源代码，构建过程需要源代码树的_快照_。高级构建系统会在虚拟机或模拟器甚至两者中设置单独的环境进行构建。
git OBS 源代码存储
新的git OBS后端增强了当前的源代码服务器，增加了git支持，但并未替换它及其当前的版本控制系统。该设计旨在与现有安装无缝协作。用户可以逐步采用新功能。但他们也可以直接使用git。
亮点列表
- 同一个git仓库可以管理一个软件包的不同版本（例如，不同的分支、git树共享），后端将跟踪主分支或指定的其他分支。git push可以触发构建过程 - 通过属性控制
- git树映射启发式可编程，以强制执行项目范围的规则（项目或软件包范围），在源代码导入时
- 可以从这样的git树中克隆git树，并使用多个软件包来生成多软件包项目
- 可以自动导入src.rpm（debian src）集合来构建git树集合
- 通过属性进行维护概念与git发布工作流协同工作 - 通过属性
- 允许自动创建不同的标准化软件包格式（deb和rpm）
- 在本地树上进行合并/分支/cherry-pick
- BSDB后端无需切换，现有的软件包可以转换为支持git的软件包
使用BSDB存储的方案
当前的修订控制系统是线性的，存储扁平的文件目录，没有层次结构。它针对存储主要是二进制文件进行了优化，这些二进制文件用于debian或rpm软件包以包含源代码和/或大量其他数据。文件层次结构或许多文件的集合存储在归档文件中。修订控制当前在软件包级别工作，没有项目范围的修订文件管理。文件无法在修订控制的基础上在软件包之间关联。
mls：实际上，源代码链接就是这种关系。
Martin：_链接不被认为是版本控制系统功能，而是OBS和版本控制的混合体。
git OBS存储的关键特性
git OBS源代码服务器存储改变了局面。它将真正的git后端引入OBS源代码服务器。它允许以与底层源代码管理发布管理相同的方式管理OBS项目，例如使用分支和标签。git OBS后端除了通常的git功能外，还引入了下一章中描述的以下功能。
下面是一个图示，说明git_backend如何与它所通信的当前组件配合使用。src_server是git_backend的停靠点。它在OBS内部提供构建/工作者所需的快照。
[worker]
[worker]
[worker]
|
\|/ (pull on request)
+-------------+ <- snapshots of tree for build <- +-------------+
[ src_server ] -> push to git if enabled -> [ git_backend ]
+-------------+ +-------------+
/|\ \ / /|\
| \_auth through routes in api/frontend_+--------+
| e.g. http://api.f.b/git/prj/pkg |
(+LDAP)
osc git
- src_server：为构建过程/工作者提供源代码快照（快照缓存）。
- git_backend：git后端由一个git服务器和用于更新构建过程所需的源代码快照的功能组成。
- osc：Osc将能够签出快照 - 主要挑战是在git树和使用osc进行的签入之间实现互操作性。
- git：Git可以使用像任何其他远程git服务器一样克隆/提取/推送。
mls：嗯，我不确定为什么需要git_backend服务器。如果后端直接使用git对象，不是更容易吗？当前的srcmd5将只是git提交id（即id将是sha1sum而不是md5）。
JanSimon：并非所有git操作都需要在obs中执行。我们希望在这里解耦并使用src_server缓存要构建的源代码存档。
Martin：一个用例是“离线工作”，这需要osc克隆一个git克隆。跳过git服务器将导致需要在OBS后端和osc客户端中实现部分git功能。另一个用例是“耦合不同OBS实例的源代码仓库”，这在使用常规git实例进行分布式工作时很常见。
两级git存储
使用新的git OBS后端，在项目范围内引入了两级存储。这意味着有可能将文件映射到全局项目级别和软件包级别。如果需要，项目的完整或部分文件可以映射到一个git仓库。可以定义例外情况，在软件包级别上，可以映射到自己的git仓库，以进行额外的或替代的归档文件。现在可以通过将文件的一部分或全部分配给相同的git仓库来将项目关联到彼此，从而提供项目级别的版本控制和项目间的版本控制，用于发布分支等。
版本控制的元数据
此外，元数据的一部分将置于版本控制之下。这是为了补充将完整项目树置于发布管理之下，并具有潜在的项目间全局git仓库（将具有多个分支和多个软件包的git树映射到多个项目）的可能性。在Git支持的上下文中，元数据是指添加到控制git仓库和构建仓库到项目和软件包的映射的新增元数据。
mls：我认为你需要在这里解释更多，我有点困惑。你到底想完成什么？（还要记住，元数据的大部分更改不应触发软件包重建。）
JanSimon：我们希望能够跟踪prj/pkg元数据的更改，以便我们可以检查历史记录并从其他prj/pks中回溯/选择更改等等。
用例、功能、约束和测试
本章通过提炼高级功能与用例、功能和测试用例来确定架构/实现。列出的用例直接受git后端支持。
用例
以下用例分为从工作流程或使用现有git仓库构建软件包中提取的子用例。
agruen：我缺少用例：你打算如何处理git中的源代码链接？创建分支时会发生什么（以及如何完成？）。合并不同软件包的不同修订版本。如何标记特定状态（在软件包和跨软件包中）？
Martin：提案 - _链接仍然应该引用也通过git可访问的那些修订版本（例如哈希或trunk）。合并应使用git的帮助进行。
agruen：分支和合并是始终需要的基本工作流程。它们应该在用例中详细说明。本文档仍然缺少这些基本内容。
目前，分支是基于源链接实现的。Git 没有类似的概念。（例如，Git 没有包的“未展开”视图。）所以当你表示一个链接应该引用那些修订版本时，那么应该如何实现：作为修订图中的父节点，作为 _link 文件中的某种魔术标记，... ？ 如果这些依赖项表示为修订依赖图的一部分，那么 Git 的合并机制就有机会发挥作用。如果不是，那么你还有什么计划来保证合并仍然有效？无论哪种方式，请你解释一下你的想法。
基线化
基线化意味着有一个（可能固定或标记，来自固定的归档文件）基线，其中存储了大部分源代码，并且本地更改（由 git 跟踪）用于自动生成补丁文件集。基线对应于一个标签或分支点，可以对该点执行 diff、merge、rebase 等操作。基线“模式”允许以差异模式运行 git（就像当前源链接一样），而不是愚蠢地存储绝对快照，这些快照来自归档的源代码树。然后以可用的方式生成合并信息。
项目全局 git 仓库
项目全局 git 树映射的一个用例是将所有构建脚本和/或描述存储在另一个项目全局 git 树中，而不是存储在（可能从外部克隆的项目范围 git 仓库）中。例如，在一个项目中，源代码来自项目范围的外部 git 仓库（克隆），所有构建规范文件和所需的补丁都来自另一个项目范围的补丁仓库。这是基线化的项目范围变体。在“测试”部分可以找到实际示例。
离线工作
使用 git 支持当前修订控制无法实现的新工作模式：离线工作模式。要离线工作，OBS 的两个部分必须从本地副本获取其信息。git 离线工作（git 是一个分布式 SCM，你可以使用 git clone 创建完整仓库的本地副本）和存储所有构建所需的数据（预加载的二进制包缓存，每个本地包的构建信息，按构建仓库和架构）为离线工作提供修订控制信息。
这种模式只能暂时使用，构建依赖关系会在其他维护者更改软件包构建依赖关系时发生变化。与当前情况相比，使用 git 可以更容易地将源代码更改推回服务器。
耦合不同 OBS 实例的源仓库
考虑两个 OBS 系统，它们具有不同的外部可见性：一个可以通过公共互联网公开访问，另一个位于私有网络中，用于非公开开发。公共服务器包含许多开源软件包，非公共服务器仅包含有限数量的项目，用于尚未发布的开发，并且还依赖于公共服务器中的一些源代码。应该有一种方法来保持在非公开运行的项目与公共服务器的一致性，并且用户应该可以选择逐个案例地将更改（主要是源代码，但也有些元数据）推送到公共服务器。最简单的方法是如果项目的大部分数据都在修订控制下（包括大部分元数据），因为然后它们可以被推送、拉取和合并。
从另一个发行版派生发行版
有一个参考 Moblin 发行版托管在 moblin.org。它托管在一个 OBS 系统中。现在，一个 Linux 发行版希望使用大部分发行版的代码库（不是 Moblin 特定的，而是发行版特定的）从该代码库创建一个 Linux 发行版，或者他们希望将 Moblin 插件添加到他们的 Linux 发行版中。借助 OBS 的 git 支持，应该支持合并、cherry pick 和更新这样的软件包基础（在本例中为公共 moblin.org 参考）到自己的项目（在本例中为自己发行版的 Moblin 插件）。应该半自动执行管理此场景的一些操作（需要指定哪些操作）。
功能
从 git 树生成软件包
从 git 树中的一个或多个软件包生成一个或多个 OBS 软件包。使用 git，修订控制和项目/软件包是解耦的（并且修订控制成为一个一等对象）。因此，不明显的是一对一的对应关系，并且一个 git 树中也可以包含多个软件包。必须有一个接口来表达这一点。
从软件包集合生成 git 树
通过导入一组 OBS 软件包（使用现有的 OBS API）生成一个或多个 git 树。与从 git 树创建软件包的情况相反，现在多个软件包可以共享一个 git 仓库。另一方面，必须保持与创建软件包（以及当前 BSDB 源仓库）的现有 API 兼容。
git 后端属性系统的操作
新的属性系统用于实现构建的开发和 。它提供了项目范围。使用 git 后端，引入了具有项目范围的修订控制系统。将两者连接到具有项目范围的构建和源代码修订开发和维护模型是一种常见的选择。有关 的工作方式，请参阅文档。
限制
本节包含 OBS 当前状态以及底层构建过程（debian 和 rpm）中未记录、文档记录稀少或显而易见但存在的行为，这些行为无法更改，因为它们是固有存在的。约束记录的一个问题是“向后兼容性”。
兼容性
git 后端的一个约束是它必须保持与当前修订控制实现及其接口的向后兼容性。这些接口是 OBS API、当前的 osc 命令行客户端接口以及与构建过程的接口。不明显但隐式定义的接口的异常示例是
- debian 包装允许检查软件包中文件的校验和和签名
- rpm 软件包也可以通过 shell 命令检查其软件包的签名或校验和
- 具有相同元数据和相同源代码/构建描述的软件包应该产生相同的构建结果，无论使用哪种源代码控制或构建系统
- 修订控制系统必须为每个修订重现原始文件
- 构建过程以特定方式传递 debian 或 rpm 的软件包源代码，并在构建定义中进行评估，必须保持兼容
测试
测试理念是测试我们具有明确用例或明确提及的功能亮点、向后兼容性测试、边界情况以及与功能需求相关的测试。
用例测试
来自功能亮点/用例的测试用例列表是
- 将 Linux 发行版源代码树（基于 .deb 以及 .rpm）导入 git OBS（Moblin、Maemo、openSUSE、Fedora、Debian、Ubuntu）
- 设置到 git 分支的映射，并测试导入 Linux 发行版的多个版本到 OBS 的效果
- 从克隆的项目范围多包 git 仓库（KDE、Gnome、X.org）创建一个完整的项目和分支
- 从外部第一层项目范围构建控制 git 树和第二层软件包 git 树创建两层映射（Fedora）
- 测试基线化是否有效，检查提交请求、合并、更新和拉取，具有只读和可写两层 git 树
- 测试是否可以按预期使用离线模式
兼容性测试用例
向后兼容性的测试用例列表是
- 测试当软件包存在 BSDB 修订历史记录时的向后兼容性
功能测试用例
- 测试具有足够项目属性的项目支持的维护和开发模式
- 测试 git 树的共享
架构、规划和实施
架构
实现
数据保存
当前 OBS 修订控制和元数据的部分数据保存文档
- 项目全局元数据
- 项目全局属性
- 修订的软件包文件
- 软件包修订历史记录日志
- 软件包元数据
- 软件包级别属性
git 支持的数据保存扩展
- 项目全局修订元数据
- 项目全局（第一级）项目范围 Git 修订文件
- 软件包级别修订元数据
- 软件包级别（第二级）Git 多仓库修订文件
内部修订控制接口
当前 OBS 接口的部分文档
- BSFileDB::fdb_getall(x,y)
- BSFileDB::fdb_add_i(x,y,z)
- BSFileDB::fdb_getlast(x,y)
- BSFileDB::fdb_getmatch(w,x,y,z)
- BSFileDB::fdb_add_i2(u,v,w,x,y,z)
- BSFileDB::fdb_getall(x,y)