openSUSE:Build Service 私有实例软件生命周期
标记项目以从 OBS 复制项目到 OBS
在向客户交付项目时，标记您想要交付的项目版本可能很有趣。 这样的标签将在创建时用修订标记标记每个软件包，并将在以后复制该版本时启用。 在 OBS 上，您可以使用两种类型的修订标记：序列号和 MD5。 由于修订标记是每个 OBS 实例的本地信息，因此在交付项目时，最好使用 MD5。 为了方便这项任务，我创建了两个脚本：
- obstag -> 创建一个包含关联标签的软件包列表
- obs2obscopy -> 使用标签作为输入进行复制。
注意 当标签通过使用链接到远程公共 API 的本地项目在远程 OBS 实例上创建时，该标签将仅包含软件包名称，并且复制将使用当前的软件包修订版本完成。
脚本可以在这里找到 openSUSE:OBS Light Obstag
忽略给定软件包的 rpmlint 警告
rpmlint 是一个很棒的工具，但是如果您导入一个无法通过 rpmlint 检查的软件包源，并且不想修复它，您可能只想暂时忽略它。
为给定软件包停用 rpmlint 很容易。
- 使用 osc 检出软件包
- 进入项目目录
osc co myProject MyPackage cd "myProject:MyPackage"
- 创建一个名为 MyPackage.rpmlintrc 的文件
- 在该新文件中添加一个完整的阻止过滤器（这非常极端，但会起作用）
# ignore all rpmlint output
addFilter(".*")
- 添加并提交
osc add MyPackage.rpmlintrc osc commit
创建分支
单独分支
OBS 通过命令行 osc 提供了一个解决方案，用于在您自己的主项目中 创建分支，稍后通过 协作模型 请求与项目所有者集成您的更改。
项目分支
如果您正在经历创建您自己的私有 OBS 的痛苦，您可能需要支持一些大型项目。 一个常见要求是创建项目分支，这些分支代表向客户或合作伙伴交付，以便为集成过程或长期维护创建一个稳定的环境。
创建项目分支只需创建一个新项目，您将在其中复制所有软件包。 您可以使用两种方法在您的分支项目中提供副本。
- 复制 使用命令 osc copypac 复制源软件包。 如果您使用 -e 选项来扩展链接，您的分支将完全与源项目分离。 如果您以后需要在头部回溯功能，这种不相关性可能会成为一个严重的缺点。
- 链接 通过使用命令 osc linkpac 的 -r 或 -c 选项将源软件包的固定修订版本链接到您的分支。 使用这种方法，您可以将更改作为补丁引入到初始项目，这使得将来回溯潜在功能的集成更加容易。 请注意，OBS 仅会自动为简单文件（例如配置）中的更改创建补丁文件，但对软件包源代码的更改将创建一个新的 .tar.gz。 如果您使用链接，我强烈建议您创建补丁文件并在您的 spec 文件中注册它们。
技巧 :
- 创建第一个 Build Repo 后，您的分支将从头开始重建，如果您的分支包含创建构建工具的软件包（请参阅 引导），这可能需要很长时间。 您可以通过将您的 Build Repo 针对用于创建分支的源项目（所有二进制文件都可用，不需要引导）来短路系统，然后，更改构建 repo 以指向自身（不要忘记 第二阶段，否则您的分支在源项目中的第一次更改后将具有未定义的 status）。
- 源项目中的链接可能会在您的分支中迅速造成严重的困难。 没有通用的规则来处理链接以及您应该如何将它们复制到您的分支。 但是，您不能默默地复制或链接它们。 以下脚本将帮助您识别它们。
OSC="osc -A http://myobs-server.mycompany.com:444" BRANCHES="MeeGo:1.0:branch_0513 MeeGo? :1.0:branch_0513:Restricted MeeGo? :1.0:branch_0729 MeeGo? :1.0:branch_0729:Restricted" for BRANCH in $BRANCHES do echo "BRANCH: $BRANCH" packages=$($OSC ls -u $BRANCH) for package in $packages do files=$($OSC ls -u $BRANCH/$package) if [ "$files" "_link" ] ; then echo " PACKAGE: $package" fi done done
最小化编译时间
如果您正在处理被许多其他软件包引用的软件包，那么每次修改都会被一系列无用的软件包构建级联，这可能会迅速使您的 OBS 实例过载。 内核、构建工具和驱动程序是这个关键列表的一部分。
如果您正在处理这些关键类型的软件包，在开发阶段将它们隔离在针对您的参考项目构建的分支中，将为您节省许多小时，甚至几天的时间。
一旦您的更改经过测试并集成到您的分支中，您可以将您的更改重新集成到主项目中。
针对远程 OBS 仓库构建
要针对另一个 OBS 实例构建（例如，从您的私有 OBS 实例针对 MeeGo 和 OpenSUSE 构建），您有两种主要选择
- 创建项目链接
- 创建仅下载项目。
第一种方法的优点是您针对的是您不知道如何管理的远程实体，但如果该远程实体宕机，您自己的 OBS 也会宕机。 第二种方法只会从远程 OBS 下载您需要构建的内容到您的私有 OBS（完整目录的副本）。 它不会让您访问源代码、补丁和配置文件。 由于副本是在您的 OBS 上本地完成的，因此您不依赖于远程 OBS 的可用性。 更多信息请参阅
引用多个仓库
当您创建 Build Repo 时，默认情况下它将指向自身。 这意味着此项目中列出的软件包期望在其同一项目中找到所有构建依赖项。
通常情况并非如此，您将指向一个代表参考分发的项目。 可以从 Web UI 轻松进行此选择。
但是，有时，尤其是在私有 OBS 实例中混合专有代码和开源代码时，您需要来自多个仓库的软件包。
现在可以通过 Web UI 或 osc 选择 Build Repo 的多个参考仓库的方法。
使用 osc 通常更容易。 您可以在 这里 找到该方法。
在构建中使用多个仓库的副作用之一是相同名称但发布版本不同或名称不同但提供相同库的软件包之间的冲突风险。 您可以使用 OBS 项目 prjconf 中的宏 Prefer 和 Substitute 轻松解决这些冲突。
有关这些宏的更多详细信息，请参阅 这里
与 Git 集成
您可以在 这里 找到一个实用的分步 GIT 集成说明。
技巧和已知问题
openSUSE OBS 项目维护着一个技巧和窍门列表，可以在 这里 找到。