openSUSE:OBS with Git

跳转到：导航，搜索

如何在 build.opensuse.org 上使用基于 Git 的 OBS

简介

Open Build Service (OBS) 拥有自己的内部源代码管理 (SCM) 系统。 借助命令行客户端 osc，用户界面行为大致等同于 Subversion (SVN)，其中 工作副本（本地目录，您可以在其中进行工作并包含源文件的（部分）副本）传统上一次只包含来自一个选定修订版的数据，如果希望在提交历史记录中前后导航，则需要使用网络。

与 Git 同步

存在一种机制，可以将软件包源从 OBS 复制到 Git（仅此方向）。 此同步服务不可由用户控制，因此只需知道它存在即可。 openSUSE:Factory 中的软件包会同步到https://src.opensuse.org/pool/pkgname。 这对于前面提到的“离线浏览”用例来说是个好消息。 已经“git 化”的软件包将免于同步。 pool/pkgname 仓库通常包含一个名为 factory 的分支。 没有设置任何权限。 总而言之，pool/pkgname Git 仓库的总体用途有限。

从 Git 同步

由于 OBSSCM 系统在各处都已根深蒂固，因此很难直接替换它。 相反，添加了 SCM Bridge / obs_scm_bridge / scmsync 机制，它可以将软件包源从任意 Git 仓库复制到 OBS 软件包实体（再次，仅此方向）。

与其它 OBS 服务器进程一起运行的软件称为obs_scm_bridge。 配置通过 OBS 软件包实体的元数据进行 (osc meta pkg -e)

<package name="descent3" project="games">
        <title/>
        <description/>
        <scmsync>https://src.opensuse.org/jengelh/descent3#master</scmsync>
        <person userid="jengelh" role="maintainer"/>
</package>

该<scmsync>tag 指定远程位置。 可以使用 URI 片段语法 指定分支，例如，"master" 分支在此处引用。 可以指定任意 Git ref。

一旦添加了scmsynctag，软件包就会被 obs_scm_bridge 监视。 提交同步在后台异步运行。 每当 obs_scm_bridge 检测到 Git 仓库中的更改时，就会从引用的 Git 修订版中的文件中创建一个新的 OBSSCM 提交。 Git 历史记录本身不会被传输； 例如，强制推送只会导致在 OBSSCM 之上创建一个新的 OBSSCM 提交。 （假设：桥接程序会创建一个--depth=1浅克隆 Git，并使用该结果进行新的 OBSSCM 提交。）

同步通常会很快完成（几秒钟），但速度慢的网络或巨大的仓库可能会延迟完成。 （如果同步器由于 OBS 中断而无法运行，稍后通过 osc service rr 手动启动它可能会有所帮助。） 如果并且在同步器运行后，OBSSCM 历史记录将获得一个具有以下形式的新的提交消息：[info=825f56ff6136e3c958676fb574b502d157b152c361e7dd43761752cb12e926d2]（Git 提交哈希）。 可以通过众所周知的 osc log 命令查看 OBSSCM 历史记录

$ osc log games/descent3
----------------------------------------------------------------------------
r4 | unknown | 2024-09-23 13:54:57 | 880e81b6fa73957de8f254d65997d709 | 1.6.0~g226.g616f921e |

[info=825f56ff6136e3c958676fb574b502d157b152c361e7dd43761752cb12e926d2]
…

880e81b6.. 是所谓的 srcmd5，类似于 OBSSCM 提交哈希。 基于 Git 的 OBS 包的另一个工件是，OBS 修订版包含一个额外的文件，_scmsync.obsinfo.

该games/descent3此处用作示例的软件包因此，出于所有目的，都存储在 Git 中，并由 Git 进行管理。 这不会立即影响 openSUSE:Factory/descent3 或 home:contributor/descent3，因为源可以友好地复制，因为它们都仍然具有关联的 OBSSCM 副本。

检出基于 git 的 OBS 包

即使在将 OBS 包切换到 scmsync 之后，用户也不应停止使用 osc 命令行实用程序。 仅使用 Git 下载的仓库未启用 osc，并且无法在没有进一步参数的情况下使用诸如 osc r 之类的命令。

此外，使用 osc up 更新现有的工作副本，而其元数据刚刚启用 scmsync，会跳过设置本地 Git 仓库。 因此，建议丢弃发生 scmsync 切换的工作副本，并使用 osc co 重新下载。 在基于 git 的工作副本中，以下命令不再起作用，或者有替代方案，或者有条件地起作用

  • osc branch, osc bco：该命令被停用，以支持分叉 Git 仓库，或 git branch（具体取决于是否希望上传，分别）— 更多内容请参见下一节。
  • osc commit：停用以支持 git commit 和 git push。
  • osc log：显示 OBSSCM 历史记录。 对于启用了 scmsync 的软件包，您主要需要 git log，除非您想检查“低级”OBSSCM 层。
  • osc sr：对于提交到未启用 Git 的 OBS 软件包实体，可以像以前一样工作。 请记住，这将提交 OBSSCM 状态，而不是 Git 历史记录。 当从例如games/descent3(develpkg) 提交到openSUSE:Factory/descent3时，您将使用 osc sr。（截至 2025 年 2 月 25 日，openSUSE:Factory 尚未基于 git，因此 sr 是正确的。）

分支/贡献

Git 仓库仅存储代码/历史记录。 与 OBS 软件包实体不同，没有隐式构建触发器，也没有定义的概念构建工件存储。 因此，Git 分支本身不会导致任何隐式服务器端构建执行。 但这不一定是坏事。 修复 changelog 拼写错误的琐碎更改现在不再产生一个（可能是不必要的）隐式构建在您的 home: 项目中。build.opensuse.org仍然可以使用 osc build 进行本地构建，而且这可能比来自

无论如何，公共 worker 实例通常配置为仅使用 4 路并行性，而本地可以同时使用所有 umpteenth 个线程（例如 32 个）。

CEFP：检出–编辑–分叉–发布（方法 1 的待定标题）

  1. “我将如何分支/编辑（启用了 Git 的）软件包？” 像这样
  2. 编辑osc co games/descent3 && cd games/descent3
  3. descent3.spec
  4. 执行本地构建以测试它是否仍然有效，osc build
  5. git add $changed_files, git commit -m "Whatever"在浏览器中打开 scmsync URL（例如https://src.opensuse.org/jengelh/descent3）并创建一个分叉，例如在 .
  6. https://src.opensuse.org/contributor/descent3由于默认 Git 远程存储库，名为origin
  7. ，仍然指向 jengelh/descent3，因此需要添加另一个远程条目以指向您自己的分叉：git remote add my gitea@src.opensuse.org:contributor/descent3
  8. git push my
    • 只有在您希望执行服务器端构建时
    • 创建一个用于测试的虚拟项目，例如 osc meta prj -e home:contributor:test<scmsync>创建一个用于测试的软件包实体，例如 osc meta pkg -e home:contributor:test/descent3 并添加一个）并创建一个分叉，例如在.
    • 指向
  9. 查看构建完成情况）并创建一个分叉，例如在通过导航到

再次使用“拉取请求”选项卡，然后选择“新建拉取请求”在浏览器中打开拉取请求。

顺序并不重要； 可以在第一次构建之前创建分叉。

  1. FCEP：分叉–检出–编辑–发布（方法 2 的标题）
  2. 在 https://src.opensuse.org/jengelh/descent3 上分叉
  3. 创建一个用于测试的虚拟项目，例如 osc meta prj -e home:contributor:test<scmsync>创建一个用于测试的软件包实体，例如 osc meta pkg -e home:contributor:test/descent3；添加一个
  4. 行
  5. osc co home:contributor:test/descent3 && cd home/contributor/test/descent3
    • 检查 git remote -v）并创建一个分叉，例如在到较新版本的 osc 命令行实用程序（似乎是 1.10 及以上版本）将重写来自 scmsync 行的远程 URLgitea@src.opensuse.org:contributor/descent3
    • ，这是好的。 在旧的 osc 上，您需要手动执行此步骤，例如通过 git remote rm origin; git remote add origin gitea@src.opensuse.org:contributor/descent3。
  6. 编辑osc co games/descent3 && cd games/descent3
  7. git add / git commit / git push my / 查看构建完成情况
  8. 通过浏览器打开拉取请求

请注意，由于 osc sr (--cleanup) 不再可用，因此在接受 PR 时自动删除 :test 项目和软件包尚未实现。

维护者说明

src.opensuse.org 使用 git-lfs。 这对拉取请求分析有一些影响。 在命令行上，希望检查仓库外部分支需要一些额外的步骤。 考虑此工作流程

$ osc co devel:tools/grpc && cd devel/tools/grpc/
$ git ls-remote origin
ed54753dfc5efcea1f4f678be907436e7b76449d377b1060a469da9d2ea7c084        refs/pull/1/head
$ git fetch origin refs/pull/1/head
* branch            refs/pull/1/head -> FETCH_HEAD
$ git checkout FETCH_HEAD
Downloading v1.68.2.tar.gz (17 MB)
Error downloading object: v1.68.2.tar.gz (afbc5d7): Smudge error: Error downloading v1.68.2.tar.gz
(afbc5d78d6ba6d509cc6e264de0d49dcd7304db435cbf2d630385bacf49e066c): missing protocol: "No such OID\n"

在协作锻造软件（例如 GitHub、Gitea 等）上提出合并请求会将源侧提交复制到目标仓库。 这包括内部数据结构，例如提交、树和 blob。 但是，LFS 对象似乎被排除在外，因此出现了 smudge 错误报告。 从经验上看，这感觉不寻常，因为如果并且在通过 Web 界面接受合并请求时，Gitea 最终会复制 LFS 对象。 无论如何，为了在合并之前解决缺少的 LFS 对象，您需要像这样从发送仓库显式检索 LFS 对象

$ git remote add r2 https://src.opensuse.org/badshah400/grpc
$ git lfs fetch r2 ed54753dfc5efcea1f4f678be907436e7b76449d377b1060a469da9d2ea7c084
$ git checkout FETCH_HEAD
HEAD is now at ed54753 Update to version 1.68.2.

关于 scm-staging 用户指南的警告

本节包含对 在其他地方创建的 scmsync 指南 的争议点的诊断。games/descent3用作以前的占位符包。

不可写的仓库

该文档要求维护者更改 OBS 软件包实体元数据 (osc meta pkg -e games/descent3) 并使用<scmsync>https://src.opensuse.org/pool/descent3#factory</scmsync>.

这样做有问题，因为/pool/descent3仓库没有任何写入权限。 维护者无法执行 git 推送。 维护者也无法接受对/pool/descent3.

不废除开发项目

开发项目将保留...

OBS 开发项目迁移到 Git

factory-auto

当 factory-auto 机器人拒绝来自 src-o-o-forwarder 的提交，例如

devel project scmsync setting is https://src.opensuse.org/jengelh/descent3#master.
Must be https://src.opensuse.org/pool/descent3 instead.

编辑 scmsync 行通常不是正确的解决方案。 问题在于您为错误的目标（pool/descent3）创建了拉取请求，而不是 jengelh/descent3。 factory-auto 提出不当建议的错误跟踪在 scm-staging issue 55 中。

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