openSUSE:Build Service Concept GitSupport Full

跳转到：导航，搜索
开放构建服务
最终用户 - 打包者 - 开发 - 安装 - 协作 - 比较

OBS中git后端支持的新提案。

简介

提议的git后端增强了OBS当前非常基础的源代码控制，提供了一个最新的版本控制系统，其范围可以达到项目间、项目内、软件包间或软件包内。使用osc的旧客户端的提案，用于已被新提案取代。旧方法不允许对源进行项目范围的管理。需要一种新的系统，在项目和软件包级别将构建和版本控制粘合在一起，以实现这种新方法。将引入类似于“构建仓库”的抽象概念，用于构建，在项目级别用于版本控制，称为“源仓库”。

熟悉git的用户如果想了解设计思路，可以直接查看“用例”和“测试”部分，而无需研究过多的功能或实现细节。该项目由用例和工作流程需求驱动。

先前工作

2009年，有一个Google Summer of Code项目，旨在为构建服务创建一个git后端。该包含一些想法，但总体项目未能实现其目标。

另一个最近的项目产生了一个名为 [bsgit] 的工具。该工具可用于将现有的构建服务软件包导入git格式。生成的git仓库包含完整的修订历史记录，可以直接推送到未来的git后端。最重要的是，bsgit正确转换源链接（这些链接可能基于源链接本身），并演示了如何在真正的版本控制系统之上实现源链接功能。（此外，该工具可以用作一个极简的构建服务客户端：对git仓库的提交可以“推回”到构建服务。当然，像bsgit这样的客户端解决方案无法克服现有后端的根本限制，例如其非分布式架构，并且在使用bsgit时会丢失当前后端无法存储的信息。）

作者在这里发表了一个关于git如何融入构建服务以及bsgit背后的想法的演示文稿，在上。

SCM

版本控制（也称为源代码管理或（源）代码管理 (SCM)）是对存储为计算机文件的文档、程序和其他信息的更改的管理。它最常用于软件开发中，在这种情况下，团队中的人员可能会更改相同的文件。更改通常由一个数字或字母代码标识，称为“修订号”、“修订级别”或简称“修订”。例如，初始文件集是“修订 1”。当进行第一次更改时，结果集是“修订 2”，依此类推。每个修订都与时间戳和进行更改的人相关联。可以比较、恢复修订，并且对于某些类型的文件，可以合并修订。较新的设计（如git）通常通过消除对所有开发人员必须访问中央服务器的约束来支持分布式版本控制。

构建系统

构建系统从给定的源代码/源代码树生成一组二进制文件。为了使构建成功，必须满足依赖链。与SCM不同，源代码是动态目标，构建过程需要源代码树的_快照_。高级构建系统会在虚拟机或模拟器甚至两者中设置单独的环境进行构建。

git OBS 源代码存储

新的git OBS后端增强了当前的源代码服务器，增加了git支持，但并未取代它及其当前的版本控制系统。该设计旨在与现有安装无缝协作。用户可以逐步采用新功能。但他们也可以直接使用git。

亮点列表

  • 可以管理同一个git仓库的不同软件包版本（例如，不同的分支、git树共享），后端将跟踪主分支或指定的某个分支。git push可以触发构建过程 - 通过属性控制
  • git树映射启发式可编程，以强制执行项目范围的规则（范围为项目或软件包），在源导入时
  • 可以从这样的git树生成包含多个软件包的multipackage项目
  • 可以自动导入src.rpm（debian src）集合，以构建git树集合
  • 维护概念通过属性与git发布工作流程协同工作 - 通过属性
  • 允许自动创建不同的标准化软件包格式（deb和rpm）
  • 在本地树上进行合并/分支/cherry-pick
  • BSDB后端无需切换，现有的软件包可以转换为支持git的软件包

使用BSDB存储的方案

当前的修订控制系统是线性的，存储扁平的文件目录，没有层次结构。它针对存储主要是二进制文件进行了优化，这些二进制文件用于debian或rpm软件包以包含源代码和/或大量其他数据。文件层次结构或许多文件的集合存储在归档文件中。修订控制当前在软件包级别工作，没有项目范围的修订文件管理。文件不能在修订控制的基础上在软件包之间关联。

git OBS存储的关键特性

git OBS源代码服务器存储改变了这种情况。它在OBS源代码服务器中引入了一个真正的git后端。它允许以与底层源代码管理相同的方式管理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服务器一样使用clone/fetch/push。

双向归档到git映射

克服当前源代码控制限制的第一个新功能是将归档文件映射到git仓库的一种方法。当前的修订控制将源文件作为二进制文件处理，这有很多缺点。新的git OBS后端将归档文件视为一个或多个git树。这些归档文件到git树的映射可以更改为所需的任何行为。映射在两个方向上工作：在导入到git树时，以及在构建/发布时从git树生成归档文件时。

agruen：对我们来说，一个严格的要求是在不更改每个修订中的所有文件（tarball、补丁、更改和spec文件）的情况下，将现有的软件包转换为或导入git后端。以不同的方式存储tarball不是我们想要解决的问题。

两级git示例

两级git存储

使用新的git OBS后端，在项目范围内引入了两级存储。这意味着有可能在全局项目级别和软件包级别上映射文件。如果需要，项目的完整或部分文件可以映射到一个git仓库。可以在软件包级别定义例外情况，以映射自己的git仓库中的一个或多个归档文件。现在可以通过将文件的一部分或全部分配给相同的git仓库来将项目关联到彼此，从而提供项目级别的版本控制和项目间的版本控制，例如发布分支等。

版本控制的元数据

此外，部分元数据也将置于版本控制之下。这是为了补充将完整项目树置于发布管理之下（通过潜在的项目间全局git仓库 - 将具有多个分支和多个软件包的git树映射到多个项目）的可能性。在Git支持的上下文中，元数据是指新添加的元数据，用于控制git仓库和构建仓库到项目和软件包的映射。

用例、功能和测试

本章通过提炼高级功能与用例、功能和测试用例来确定架构/实施。列出的用例直接受git后端支持。

用例

以下用例分为从工作流程或使用现有git仓库构建软件包中提取的子用例。

agruen：我遗漏的用例：你打算如何处理git中的源链接？创建分支时会发生什么（以及如何完成）？合并不同软件包的不同修订版本。如何标记特定状态（在软件包和跨软件包中）？

基准测试

基准测试意味着有一个（潜在的固定或标记的，来自固定的归档文件）基线，其中存储了大部分源代码，并且本地更改（由git跟踪）用于自动生成补丁文件集。

agruen：请澄清：谁在这里做什么，结果是什么？

项目全局git仓库

项目全局git树映射的一个用例是将所有构建脚本和/或描述存储在另一个项目全局git树中（从项目全局外部git仓库克隆）。一个例子是，一个项目的源代码来自项目全局外部git仓库（克隆），而所有构建spec文件和因此需要的补丁都来自另一个项目全局补丁仓库。这是项目范围的基准测试变体。请参阅测试部分中的实际示例。

openSUSE git内核仓库

openSUSE / SLE内核git仓库可以直接用作内核软件包构建的源。不同的分支用于不同的发行版修订版本。跟踪同一git仓库的不同分支以用于不同软件包的功能将适用。该git仓库也是基准测试的一个用例。有关此仓库的更多信息，请参见https://en.opensuse.net.cn/Kernel_Git。

agruen：这不是我们的目标，不应该成为此项目的一个用例。我们目前对坚持使用当前机制提交构建服务中的快照（由在内核git仓库中运行的脚本/tar-up.sh生成）感到满意。

离线工作

使用git支持了一种当前版本控制中不可能的新工作模式：离线工作。要离线工作，OBS的两个部分必须从本地副本获取其信息。git离线工作（git是一种分布式SCM，可以使用git clone创建完整的仓库本地副本）和存储构建每个本地软件包所需的全部数据（预加载二进制软件包缓存、每个本地软件包的构建信息副本）提供用于离线工作的修订控制信息。

此模式只能暂时使用，构建依赖关系会在其他维护者更改软件包构建依赖关系时发生变化。与当前情况相比，使用git可以更轻松地将源代码更改推回服务器。

导入非git仓库

并非所有源代码仓库都使用git。要将来自CVS或Subversion的multipackage仓库导入git后端，请使用现有的版本控制仓库转换器，用于CVS到git和Subversion到git。

agruen：在这个项目中，我们感兴趣的是将现有软件包的修订版本导入git后端。我们不感兴趣于从根本上改变软件包的管理方式，我们希望保持其当前的结构：tarball + 补丁 + spec文件 + 更改文件。因此，导入上游仓库的问题不存在。

Fedora软件包仓库

从 Fedora 包种子仓库生成项目中的所有包。它们目前在 CVS 中管理，可以轻松转换为 git 并导入。有关此仓库内容的更多信息，请参见 http://fedoraproject.org/wiki/Using_Fedora_CVS。不同的 Fedora 版本和开发树位于不同的 CVS 分支中，可以映射到项目内映射。向 git 的迁移 正在讨论中，时间表为 2010 年，并且可能在 Fedora 13 发布后延迟。

agruen: 再次声明，这不是这个项目的目标。

耦合不同 OBS 实例的源仓库

考虑两个 OBS 系统，它们具有不同的外部可见性：一个可以通过公共互联网公开访问，另一个位于私有网络中，用于非公开开发。公共服务器包含许多开源包，非公共服务器仅包含有限数量的项目，用于尚未发布的开发，并且也依赖于公共服务器中的一些源。应该有一种方法来保持非公开运行的项目与公共服务器的一致性，并且用户应该可以选择逐个案例地将更改（这里主要是源代码，但也包含一些元数据）推送到公共服务器或从公共服务器拉取。如果项目中的大部分数据都受到版本控制（包括大部分元数据），这将是最简单的方法，因为然后它们可以被推送、拉取和合并。

从另一个发行版派生一个发行版

有一个参考的 Moblin 发行版托管在 moblin.org。它托管在一个 OBS 系统中。现在，一个 Linux 发行商希望使用大部分发行版的代码库（不是 Moblin 特定的，而是发行版特定的）从该代码库创建一个 Linux 发行版，或者他们希望将 Moblin 插件添加到他们的 Linux 发行版中。借助 OBS 的 git 支持，应该支持将这样的软件包库（在本例中为公共 moblin.org 参考）合并、挑选和更新到自己的项目（在本例中为自己发行版的 Moblin 插件）。一些管理此场景的操作应该半自动（需要指定哪些操作）。

功能

从 git 树生成包

能够使用 git 树作为包源代码。

agruen: 请澄清。

从包集合生成 git 树

能够将一组包导入到 git 树/git 树中。

agruen: 请澄清。

属性系统与 git 后端的交互

新的属性系统用于实现构建的开发和 。它提供了项目范围。使用 git 后端，引入了具有项目范围的版本控制系统。将两者连接到具有项目范围的构建和源代码修订开发和维护模型是一种常见的选择。关于 的工作方式有文档说明。

测试

测试理念是在我们有明确用例或明确提及的功能亮点、向后兼容性测试、边缘情况以及与功能需求相关的测试的情况下进行测试。

用例测试

来自功能亮点/用例的测试用例列表是

  • 将 Linux 发行版源代码树（基于 .deb 以及 .rpm）导入到 git OBS（Moblin、Maemo、openSUSE、Fedora、Debian、Ubuntu）
  • 设置到 git 分支的映射，并测试导入一个导入的 Linux 发行版的多个版本到 OBS 的效果
  • 从克隆的项目范围多包 git 仓库（KDE、Gnome、X.org）创建一个完整的项目和分支
  • 从外部第一层项目范围构建控制 git 树和第二层包 git 树创建两层映射（Fedora）
  • 使用 openSUSE / SLES 公共 git 仓库的内核树示例工作流程
  • 测试基准是否有效，检查提交请求、合并、更新和拉取，具有只读和可写的两层 git 树
  • 测试是否可以使用离线模式

兼容性测试用例

向后兼容性的测试用例列表是

  • 测试当 BSDB 修订历史存在于包中时的向后兼容性

功能测试用例

  • 测试具有足够项目属性的项目支持的维护和开发模式
  • 测试 git 树的共享

架构、规划和实施

规划和 TODO 列表

有一个单独的

数据保留

  • 项目范围 Git 仓库信号
  • 包范围 Git 仓库信号
  • 项目范围元数据 Git 仓库信号

细节待指定

待指定的细节列表

问：将配置数据保存在哪里：配置文件还是属性系统
答：两层 git 需要属性系统或“meta prj”。包可以使用纯元文件。

Explanation: A project in the build service has no file storage associated as a package does for tarballs/spec.
             Thus the git-metadata for projects need to be stored either alongside the project's obs-metadata
             (osc meta prj) or in the new attribute system.
项目/包 git 元数据概述

问：项目范围的 git 元数据可能是什么样子
答：

问：包 git 元数据可能是什么样子
答：

问：什么是“两层 git”？
答：“两层 git”描述了一种项目/包设置，其中项目元数据（obs-meta 和项目范围的 git 元数据）存储在“build-config”git 树中，实际的包源存储在一个或多个“source”git 树中。这是 OBS+git 后端的 Fedora 构建 CVS 树版本。git 后端服务器必须获取和部署

  • prjconf（参见 osc meta prjconf）
  • prj（参见 osc meta prj）
  • git_prj_config 或属性（待定）

git_prj_config 然后保存有关“build-config”树的信息，其中各个包获取其数据，以及如果未在包中覆盖，则“source”git 树的默认设置。例如：Gnome 或 KDE 仓库可以使用 git 树来存储“build-config”相关文件和他们自己的项目 git 树来存储源。从而将发行版构建定义和补丁与源分离。

问：如果使用仅 git 包，osc 构建如何工作
答：使用 osc 动态创建 tarball

问：如果使用 git 且使用树内 specfile，osc 的工作目录设置如何
答：它可能如下所示

.osc <dir>
package <dir>  = cloned git tree
package.tar.bz2
package.spec
package.patch

问：如果使用树内 specfile，osc 如何提交
答：拆分/合并 specfile

问：osc 与 git 树的集成 A

  • osc git initrepo
  • osc git setrepourl
  • osc git

问：提交请求映射 osc -> git 树 A

  • 推送到 git 作为分支
  • hermes 消息集成待定

问：如果使用外部源仓库，安全注意事项是什么？
答：所有 git 操作都在自己的 chroot 环境中完成 - 类似于 workers 或 src_service。

正在调查

调查点列表

  • git 服务器和通过 webdavs 访问（通过 api 路由访问 - 例如 http://api.linux.com/git/prj/pkg）
  • git 服务器的钩子
    • 钩子将事件发送到 git 后端
  • ldap 集成可能性
  • 如果存在 BSDB，osc 中的日志
  • 将 git 历史记录导入 osc 日志
  • tar 文件中仅有 checksum 的 payload

交叉检查问题列表

  • Q01：如何指示 git 版本控制的二进制归档文件
  • Q02：如何指示归档文件是重现 payload 还是二进制相同的（后者需要二进制副本）。它们需要构建（例如，具有 checksum/signature 的 debian）
  • Q03：元数据的版本控制应该实现到什么程度
  • Q04：将归档文件映射到 git 树是否会显著降低性能，因此我们是否需要缓存
  • Q05：如何最好地压缩多个修订版的二进制文件

使用 OBS git 支持

示例

从 "https://en.opensuse.net.cn/index.php?title=openSUSE:Build_Service_Concept_GitSupport_Full&oldid=171139" 检索