关于开放源代码:我的-openEuler-社区参与之旅

80次阅读

共计 14216 个字符,预计需要花费 36 分钟才能阅读完成。

openEuler 是什么?

openEuler 是一个开源、收费的 Linux 发行版平台,将通过凋谢的社区模式与寰球的开发者独特构建一个凋谢、多元和架构容纳的软件生态体系。同时,openEuler 也是一个翻新的平台,激励任何人在该平台上提出新想法、开辟新思路、实际新计划。

装置界面:

openEuler 的官方网站: https://openeuler.org/

repo 下载地址: https://repo.openeuler.org

文档手册:https://openeuler.org/zh/docs/20.03_LTS/docs/Releasenotes/release_notes.html

openEuler 版本怎么布局?

阐明:

  1. 有翻新版本和 LTS(Long term support)版本两条线的版本。
  2. 遵循 Upstream First 准则,软件带包间接来源于原生社区,并反哺原生社区。
  3. master 分支即为以后最新版本开发分支,一旦公布翻新版本或 LTS 版本,

    openEuler 翻新版本(非 LTS)openEuler LTS 版本版本定位构筑开发者生态,新个性沉闷,版本演进快反对合作伙伴构筑商业发行版公布周期 0.5 年 2 年保护周期 0.5 年 4 年 or more 质量标准低,对标 fedora 品质要求中,对标 centos 品质要求要害工作 新个性、bugfix、CVE、降级选型等 无限个性、bugfix、CVE 对应分支以后无,下一个版本 openEuler-20.09 最新分支 openEuler-20.03LTS

openEuler 版本如何构建?

openEuler 构建模型:

版本如何构建:

阐明:

名字阐明备注码云 openuler Group 这个组织下寄存的都是由 openEuler 社区发动的原生我的项目,相当于一个一个的上游社区。例如 isula、atune 我的项目。https://gitee.com/openeuler 码云 src-openeuler Group 这里寄存的是以 rpm 源码模式的代码。每个仓库源码都能够间接构建 rpm 二进制。https://gitee.com/src-openeulerOBSopen build service,opensuse 公布的一套开源构建零碎,相似于 koji、yacto 等。https://build.openeuler.orghttps://openbuildservice.orgjenkinsCI/CD,继续集成平台,次要用于门禁工作、版本构建任务调度等 http://114.116.250.98/repo 用于归档公布的交付件及 yum 软件源。https://repo.openeuler.org/

openEuler 版本里有啥软件?

最直观的形式是拜访 openEuler 官网 repo,看看公布件。

公布件 构建工具 Repo归档地址ISO:Dvd ISO、Debuginfo ISOEverything ISOSource ISOmkdvdiso(待开源)、kiwihttp://repo.openeuler.org/openEuler-20.03-LTS/ISOQcow2 镜像 CreateImage(待开源)http://repo.openeuler.org/openEuler-20.03-LTS/docker_img 容器镜像 kiwihttp://repo.openeuler.org/openEuler-20.03-LTS/virtual_machine_imgLiveCD?…

另外一种形式,就是拜访 openEuler OBS 上的构建工程,能够晓得每个版本里蕴含哪些软件,以后的构建状态是啥样的。

版本 OBS 工程阐明束缚地址 master 骨干 openEuler:Factory(新包引入)新软件退出,首先引入到 openEuler 软件工场,master 分支代码构建 rpm,不会集成到 iso 或 repo 中 https://build.openeuler.org/project/show/openEuler:Factory openEuler:Mainline 主线工程,master 分支代码外面波及的包都会随着 openEuler 的版本公布 https://build.openeuler.org/project/show/openEuler:MainlineLTS 版本 openEuler:20.03:LTSLTS 版本构建工程,openeuler-20.03-LTS 分支代码 https://build.openeuler.org/project/show/openEuler:20.03:LTS20.09 版本(未拉分支)—  —

软件是如何治理的?

openeuler 源码仓库治理:

  • openEuler 所有代码托管在 gitee.com
  • 有 openeuler、src-openeuler 两个 group
  • 都是源码化、配置化治理

groupopeneulersrc-openeuler定位代码仓、原生社区软件包仓、制品仓内容 openEuler 发动的原生我的项目 spec rpm 格局归档的软件包仓库 URLhttps://gitee.com/openeulerhttps://gitee.com/src-openeuler 仓库数量 50+2500+ 代码治理源码树 src rpm 格局关系是 src-openeuler 的上游社区

以后 openEuler 软件的治理是 以 sig 组来承载 ,所有的软件 惟一的归属于某个 sig。通过 sigs.yaml 文件,你能够查问到该软件属于哪个 sig,并通过 sigs 专有归档目你能够查问对应的 maintainer。只有对应的 maintainer 才有对应仓库代码合入权限。

openeuler/community 仓库下,以下三个文件比拟重要:

sig/sigs.yaml 治理和保护各 sig 下保护的软件包,划分 sig 治理的软件包范畴。

repository/openeuler.yaml openeuler 下保护的软件包仓库信息。

repository/src-openeuler.yaml) src-openeuler 下保护的软件包仓库信息。

通过批改这几个文件,来新增、删除软件包仓库,来给相应的软件包划分 sig,从而实现 sig 的 owner 对软件包的权限治理。

理解 openEuler SIGs

SIG 就是 Special Interest Group 的缩写,openEuler 社区依照不同的 SIG 来组织,以便于更好的治理和改善工作流程。

  • SIG 组和 SIG 的邮件列表是凋谢的,欢送任何人和个人退出并参加奉献。
  • SIG 都是针对特定的一个或多个技术主题而成立的。SIG 内的成员推动交付成绩输入,并争取让交付成绩成为 openEuler 社区发行的一部分。
  • SIG 的核心成员主导 SIG 的治理。请查看 SIG 的角色阐明。您能够在奉献的同时积攒教训和晋升影响力。
  • 每一个 SIG 在 Gitee 上都会领有一个或多个我的项目,这些我的项目会领有一个或多个 Repository。SIG 的交付成绩会保留在这些 Repository 内。
  • 能够在 SIG 对应的 Repository 内提交 Issue、针对特定问题参加探讨,提交和解决问题,参加评审等。
  • 您也能够通过邮件列表、IRC 或视频会议和 SIG 内的成员进行交换。

openEuler SIG 保护策略

  1. 依据所有软件所波及畛域和方向,openEuler 曾经垂直的划分了很多根底的 SIG。
  2. 每个独立软件要归属到惟一 SIG 里,SIG 的 maintainer 治理该 SIG 波及的软件包,并定期扫视。
  3. SIG 之间要防止正交、耦合,粒度要正当,治理的软件仓规模防止太大。
  4. 新成立 SIG 时,应提前理解以后 openEuler 是否曾经存在雷同或相似的 SIG。
  5. 新 SIG 申请时,应思考和其余 SIG 沟通,将该 SIG 畛域波及软件一并接管过去。
  6. SIG 的成立、经营、废除受 TC 委员会监管。

openEuler 社区开发全景?

上图是 openEuler 社区开发指引图。

阐明:

  1. 软件包治理依照软件包所处的工夫点分为:

  1. 每个阶段的输出是圆框绿底,如

  1. 所有的开发和保护动作是由 issue 触发。issue 可分为需要、问题、CVE 等类型。

  1. 所有批改和操作通过 PR 来发动。
  2. 全景图中,每个动作都可能波及标准或领导。将在前面以表格的形式整顿出现。

全景图中波及的标准:

阶段动作标准或领导引入

领导:《如何申请 SIG》– 待输入 –

标准:《软件包引入和退出要求》领导:《openEuler 加包领导》– 待输入 –

标准:《软件包打包标准》开发 & 保护

标准:《软件包降级选型标准》– 待输入 –

领导:《软件包打包标准》

标准:《软件包打包标准》领导:《如何提交 PR、发动检视及合入验证》– 待输入 –

标准:《openEuler 破绽解决流程》标准:《openEuler 破绽严重性评估》领导:《如何申请 CVE、破绽上报》

标准:《openEuler 软件包随版本公布标准》– 待输入 – 领导:《如何将软件包退出 openEuler 公布版本》– 待输入 –

标准:《安全漏洞解决和公布流程》退出

标准:《软件包引入和退出要求》

如果参加 openEuler 社区奉献?

第一步,开源并不象征者得心应手,签订 CLA:“贡献者许可协定”是第一步,浏览并恪守 openEuler 社区的行为守则;

第二步,从理解、装置、应用、测试 openEuler 开始,踊跃反馈问题和倡议,相干的文档和手册,以及相干的资讯能够帮忙你更加深刻的理解 openEuler。

第三步,开发者相熟社区的开发流程后——《贡献者指南》,能够基于本人感兴趣的我的项目和软件,在码云上 openEuler 对应的我的项目提交本人的奉献。

理解 gitee 工作流

  • 筹备工作
  • Fork 仓库

  • 克隆到本地

  • 拉分支
  • 批改验证提交
  • 推送到码云
  • 创立 PR

  • 关注代码审查意见

  • 更新 PR

倡议:

  1. 相干的批改,独自拉分支来批改提交,并创立 PR。如果能够,一次 commit 一个分支。
  2. 当 PR 合入后,能够强制同步最新代码到集体仓库。

  1. 不要在 master 上提交代码,当 PR 未 merge 时,强制同步会失败。

开发者能够在 openEuler 社区做些什么?

包含但不限于:

  • 提交一些需要,并尽可能实现它
  • 提交一个 bug 并修复它
  • 上报破绽及破绽解决
  • 提出一些倡议,包含不限于网站改良、文档改良、流程标准改良、体验晋升等。
  • 为社区增加新的软件
  • 发动社区新我的项目

联合后面的开发者全景图,能够分解成以下动作:

1、创立 issue,提交需要 & 问题 & 倡议

  • 提出问题 :如果您发现并想向社区上报问题或缺点,问题提交的形式就是创立一个 Issue。您只有将问题以 Issue 的形式提交到该我的项目 Repository 的 Issue 列表内,并查看 Issue 提交指南以获取更多的信息。提交问题时, 请尽量恪守 问题提交准则。
  • 提出倡议:如果您想对 SIG 畛域内奉献出本人的意见或倡议,也能够通过提交 Issue 的形式分享给大家。大家能够在该 Issue 上充沛的交换和探讨。为了吸引更宽泛的留神,您也能够把 Issue 的链接附在邮件内,通过邮件列表发送给所有人。
  • 提出需要 :如果你心愿某个个性或是技术在 openEuler 上落地,能够提交需要类 issue, 清晰残缺的形容有助于团队成员了解,并被更快的承受和排入开发计划。

2、提交 PR,修复一个问题(bug、cve、新个性)

当你提交一个 PR 的时候,就象征您曾经开始给社区奉献代码了。请参考 openEuler 社区 PR 提交领导 与 码云 PR 提交流程。

注意事项

  • openEuler 只承受 PR 的模式来提交代码,不容许间接向 openEuler 下的仓库间接 push 代码。
  • 首先,要找到修复问题对应的仓库,以 src-openEuler/mock 为例,点击 fork 按钮,复制仓库代码到集体名下。

  • 将代码 git clone 到本地,如果你的批改不波及二进制源码软件包的变动,将所批改的代码做成一个 patch,因为仓库是以 rpm 源码包的格局组织的。
  • 每个 PR 都会触发 openEuler 门禁的查看,包含不定命名、代码标准、代码构建。门禁的后果会稍后回显在评论中,存在失败的查看项要及时修改。
  • 通过门禁中的 openeuler-rpm-build 的链接,你能够逐层找到这次提交构建的长期 rpm 二进制。后续会将生成的二进制间接回显到评论里。

  • 代码 reviewers 能够针对提交给出本人意见,当他认可你的提交时,会 /lgtm 来给出 ok 的意见。
  • 仓库的 maintainers 有合入的权限,/approve的评论会触发 robot 主动合入,如果存在抵触,你须要提前解决抵触。
  • 针对他人给出的检视意见。如果波及批改代码,能够应用 git commit --amend;git push -f 来在同一个 PR 更新 PR。

检视代码:

openEuler 是一个凋谢的社区,咱们心愿所有参加社区的人都能成为沉闷的检视者。能够参考社区成员,该文档形容了不同贡献者的角色职责。

对于贡献者,为了使您的提交更容易被承受,您须要:

  • 遵循 SIG 组的编码约定,如果有的话
  • 筹备欠缺的提交信息
  • 如果一次提交的代码量较大,倡议将大型的内容分解成一系列逻辑上较小的内容,别离进行提交会更便于检视者了解您的想法
  • 应用适当的 SIG 组和监督者标签去标记 PR:社区机器人会发送给您音讯,以不便您更好的实现整个 PR 的过程

对于检视者,强烈建议本着行为准则,超越自我,相互尊重和促成合作。《补丁审核的柔和艺术》一文中提出了一系列检视的重点,阐明代码检视的流动也心愿可能促成新的贡献者积极参与,而不会使贡献者一开始就被轻微的谬误吞没,所以检视的时候,能够重点关注包含:

  • 奉献背地的想法是否正当
  • 奉献的架构是否正确
  • 奉献是否欠缺

留神:如果您的 PR 申请没有引起足够的关注,能够在 SIG 的邮件列表或 dev@openeuler.org 求助。

这里是一个可供参考的示例。

3、创立兴趣小组

stateDiagram

[*] –> 查找 sig 列表

查找 sig 列表 –> 退出 SIG : 已存在

查找 sig 列表 –> 按模板提交 PR : 不存在

按模板提交 PR –> 订阅邮件,申请议题

订阅邮件,申请议题 –> TC 评审

TC 评审 –> 合入 PR : 评审通过

TC 评审 –> 按模板提交 PR : 不通过

合入 PR –> [*]

退出 SIG –> [*]

SIG 列表:gitee.com/openeuler/community/tree/master/sig

TC 邮件列表:gitee.com/openeuler/community/tree/master/zh/technical-committee

PR 模板:gitee.com/openeuler/community/tree/master/sig/sig-template

提交示例:gitee.com/openeuler/community/pulls/398

找到您感兴趣的 SIG 或我的项目

找到您感兴趣的 SIG 组,能够帮忙您在正确的中央提出问题,并失去更快的社区响应。

  • 形式一:如果您不理解有哪些 SIG 或我的项目,您能够查看 SIG 列表,它蕴含以后 openEuler 社区成立的所有 SIG 团队的清单。您能够通过该列表疾速的定位到您感兴趣的畛域所对应 SIG 团队。同时还会向您提供该 SIG 团队的如下信息:SIG 下的我的项目,以及我的项目的 Repository 地址 SIG 内的交换形式,包含邮件列表、IRC 或视频会议等 Maintainer 的联系方式
  • 形式二 :如果您晓得感兴趣的项目名称,能够在 openEuler 的 Repository 列表下进行含糊搜寻,从而疾速定位到对应我的项目的首页地址。通常状况下,在该我的项目首页地址的README.md 文件中,能够找到该我的项目所属的 SIG 信息、交换形式、成员和联系方式等。

如果上述两种形式都定位不到您感兴趣的 SIG,您能够向 community@openeuler.org 发求助邮件。建议您在邮件列表内用“【开发过程疑难】”作为题目,在内容中写出你寻找的 SIG 或我的项目的特色,咱们会为您提供帮忙。

确定好你要创立小组后,能够依照模板创立一个新的 sig 目录,并提交 PR 到 community 仓库,并在 TC 例会上申请议题(订阅 tc@openeuler.org,并关注议题收集的邮件),通过大家一致同意后,合入 PR,就代表 sig 创建胜利。

这里是一个 PR 提交创建 sig-golang 的具体例子,包含 sig 的 raodmap、职责、治理的仓库(兴许是从别的 sig 中移交过去)、联系方式和 maintainer 等信息。

4、奉献软件包

stateDiagram

[*] –> 查找软件

查找软件 –> [*] : 已存在

查找软件 –> 引入软件 : 不存在

引入软件 –> 确定所属 SIG

确定所属 SIG –> SIG 是否存在

SIG 是否存在 –> 创立 SIG 兴趣小组 : 不存在

SIG 是否存在 –> 对应 SIG 下增加仓库 : 存在

对应 SIG 下增加仓库 –> 评审合入

评审合入 –> [*]

以后发现 openEuler 社区短少你须要的软件时,你能够尝试入手为社区奉献软件包。这里不再赘述 OS 是如何由 linux 软件包组成的,以及如何制作一个 rpm 包。这里着重解说奉献软件包的流程。

  • 首先,要明确奉献的软件包的性能,遵循 openEuler 软件包引入和退出准则。
  • 再者,因为软件惟一的归属于一个 sig,你须要查看以后是否有适合的 sig 承载,如果没有,须要你依照步骤 3 申请成立一个新的 sig。
  • 而后,你能够通过提交 PR 的形式,在对应的 sig 下增加软件仓库。可参考这个提交,一旦审核通过,后盾会主动为你在对应的 src-openeuler group 下创立同名仓库,并在 Factory 工程中去创立同名 package 开始构建,因为默认仓库里只有 readme,并不会进行真正的构建,而是 exclude 状态。

  • 接着你能够依照 2 的操作提交一个 PR,来上传能够构建的代码。一旦合入,Factory 工程便会触发构建。

  • 软件打包合乎打包标准,请参考如何打包。
  • 该工程下所有软件包胜利的构建后果,归档在:

openEuler OBS 应用

这两片文章帮忙你理解 obs 的根本应用。如何应用 openEuler OBS –(一)介绍 和如何应用 openEuler OBS –(二)与 gitee 的联动

什么是 obs?

OBS 是 Open Build Service 的简写(官网网址:https://openbuildservice.org/),

本来是作为发行版 openSUSE 专用的 rpm 打包的平台,后续扩大为面向多发行版、多架构、多格局的打包公布平台。

与 koji 的不同

  • 治理范畴

与 koji 只治理包(包含源码包与二进制包)仓库不同,OBS 同时治理着源码与包两个仓库。koji 是从一个包编译实现后开始接手,依据包的 NVR(Name-Version-Release)确定包的地位,在编译验证后入库保留。而 OBS 是从源码阶段开始治理,它领有本人的包版本标记与 changelog 日志。OBS 能够像 git 一样保留源码的历史版本,对源码进行分支治理。并生成各版本的二进制包与源码包。

换句话说,OBS 能够同时实现 koji 和 git 的性能。> OBS 承受源码的格局与 git 广泛的保留格局并不相同,所以 OBS 无奈齐全取代 git。

  • 实用格局

OBS 能够生成 rpm、deb 等格局的包,而 koji 只实用于 rpm 格局。

  • 反对 Rest API

不便测试框架、构建工程调用。

如何配置 obs

装置 osc

osc 是 OBS 的命令行程序,您能够在这里,抉择本人的零碎版本,增加软件源到本身包管理器中。

这里以 Fedora30 为例:

  1. 增加软件源

将文件 http://download.opensuse.org/repositories/openSUSE:/Tools/Fedora_30/openSUSE:Tools.repo 另存到 /etc/yum.repo.d/ 中。> 须要 root 权限。

  1. 装置 osc

执行 dnf install osc 命令装置 osc。

配置 openEuler 的 OBS

有很多办法能够将 osc 链接至 openEuler 外网的 OBS:

  1. 最根底的办法为在每次执行 osc 命令时增加参数:-A http://openeuler-build.huawei.com/
  2. 应用 alias:alias iosc="osc -A http://openeuler-build.huawei.com/"
  3. 批改位于 home 目录下的 osc 配置文件:vi ~/.oscrc,并写入以下内容:

注册 OBS 账号

关上 http://openeuler-build.huawei.com/,点击右上角“Sign Up”,注册本人喜爱的帐号。

注册实现后,从新回到下面网址。点击右上角的“Login”,用新账户登录。零碎会在注册时主动创立一个以“home: 用户名”为格局命名的 Home Project。

后续须要邮箱向 infra@openEuler.org 申请。

OSC 命令

osc help 是帮忙指南。相似 git 命令。

List Existing Content on the Server

osc ls #list projects

osc ls Apache #list packages in a project

osc ls Apache flood #list files of package of a project

Checkout Content

osc co Apache # entire project

osc co Apache flood # a package

osc co Apache flood flood.spec # single file

Update a Working Ddirectory

osc up

osc up [directory]

osc up * # from within a project dir, update all packages

osc up # from within a project dir, update all packages AND check out all newly added packages

Upload Changed Content

osc ci # current dir

osc ci [file1] [file2] # only specific files

osc ci [dir1] [dir2] … # multiple packages

osc ci -m “updated foobar” # specify a commit message

Check the Commit Log

osc log

Show the status (which files have been changed locally)

osc st

osc st [directory]

If an update cannot be merged automatically, a file is in ‘C’ (conflict) state, and conflicts are marked with special lines. After manually resolving the problem, use osc resolved *FILE*.

Mark files to be Added or Removed on the Next Checkin

osc add foo

osc rm foo

Add all New Files in Local Copy and Removes all Disappeared files

osc addremove

Generate a diff to view the changes

osc diff [file]

Show the Build Results of the Package

osc results

osc results [platform]

Show the Log File of a Package

(you need to be inside a package directory)

osc buildlog [platform] [arch]

在本地机器上构建

osc build [platform] [arch] [specfile] [–clean|–noinit|…]

以 abuild 用户进入 chroot 环境,不便调试

osc chroot [platform] [arch]

如何创立本人的工程,package

配置 Project

两种办法:网页操作、命令行操作

  • 网页操作:

在 obs 主页点击右上角

顺次进入 Home Project -> Repositories -> Add from a Distribution。

按上图所示填写根底配置,并在 Name 栏填写喜爱的名字。

在抉择后后退至 Repositories 界面,能够看到如下图所示的环境:

  1. 第一个为编辑按钮,能够抉择以后发行版编译架构
  2. 第二个为增加按钮,可在发行版规范环境上额定增加独自的包(例如其余私人编译的依赖包)
  3. 第三个为下载,点击后转到以后环境的仓库
  4. 第四个为删除
  • 命令行操作:

执行命令:osc meta prj -e [project 名],会看到相似如下文本:

其中,1. repository 标签为仓库标签,可增加此项增加编译时的根底环境 2. Path 标签为可用包门路标签,需手动增加发行版包门路。如须要额定依赖,也能够独自增加。3. Arch 标签为编译架构,可同时增加多个。

例如:

`xml

<repository name=”openEuler_selfbuild_BaseOS_beiyong_aarch64″>

<path project=”openEuler:selfbuild:BaseOS” repository=”mainline_standard_aarch64″/>

<path project=”openEuler:selfbuild:BaseOS” repository=”standard_aarch64″/> // 此为额定增加依赖

<arch>aarch64</arch>

<arch>armv7l</arch> // 此为多架构选项

</repository>

`

新建包

进入 Project 目录:cd [project 名]

新建 Package:osc mkpac [package 名]

进入 Package 目录并将下载源码以【tar 包、所有 patch、spec 文件、其余 source 文件】格局搁置:

向新创建的 package 中增加以上文件:osc add *

将更改上传至服务器:osc commit

在这里能够注明本次上传的简短介绍,用 :wq 保留并退出

之后就能够在网页上期待编译并查看后果了。

查看包状态与下载包

您能够在 Project 与 Package 主页右侧看到以后编译状态

  • finished 示意在某个零碎平台执行编译链接、装置查看的过程完结
  • succeeded 状态为编译胜利
  • failed 为编译失败,您能够点击查看日志

您能够点击_编译平台 -> Go to download repository_ 达到编译仓库,取得此 Project 的 repo 源与所有编译胜利的 package。

更新包

进入 project 文件夹:cd [project 名]

更新本地代码为最新代码:osc up

进入 package 目录,应用 osc add 命令将新文件增加到 package,批改 spec 文件后应用 osc commit 命令上传新版本。

_service 的应用,与码云的联动

分为两局部:

  • 利用 Source Services(下称源服务)间接获取 git 源码并编译成包
  • 利用 webhook 使源服务在 git 仓库 push 时触发,从而实现 OBS 始终跟进 git 仓库最新版本源码的成果

利用源服务间接获取 git 源码并编译成包

Source Services 相干

Source Services 是用于以牢靠形式验证,生成或批改源的工具。它们被设计为最小的工具,并且能够依照经典 UNIX 设计的弱小思维进行组合。

源服务就像是零碎中的函数,咱们能够通过运行脚本调用它;而脚本就是 Package 中的_service 文件。

创立应用源服务的 Package

  1. 通过命令行工具或者网页新建一个空的 Package

  1. 进入 Package 目录并创立_service: 网页端点击_Add file_,点击_Choose a file_,并抉择本地建好的_service 文件。命令行则在 Package 目录中新建_service 文件并上传之服务器。
  2. 筹备编辑_service 文件

编辑_service 文件

最根底的_service 文件将会如下所示:

<services>

<service name=”tar_scm”>

<param name=”scm”>git</param>

<param name=”url”>git://github.com/cs2c-fu/hi.git</param>

</service>

<service name=”recompress” mode=”buildtime”>

<param name=”compression”>xz</param>

<param name=”file”>*.tar</param>

</service>

<service name=”set_version” mode=”buildtime”/>

</services>

最外层为 标记,在 内则为一个个 函数,而 则为 “ 函数的参数。

为了实现“利用源服务间接获取 git 源码并编译成包”这个指标,

咱们的_service 应该相似于这样(以下格局请依据具体情况抉择适合的程序):

<services>

<service name=”tar_scm”>

<param name=”scm”>git</param>

<param name=”filename”>helloworld</param>

<param name=”url”>git://github.com/cs2c-fu/hi.git</param>

<param name=”versionprefix”>VERSION.git</param>

</service>

<service name=”extract_file”>

<param name=”archive”>.</param>

<param name=”files”>/.spec /.patch</param>

</service>

<service name=”recompress” mode=”buildtime”>

<param name=”compression”>xz</param>

<param name=”file”>*.tar</param>

</service>

<service name=”set_version” mode=”buildtime”/>

</services>

上面将对所需的服务逐个进行介绍:

第一个服务:tar_scm

tar_scm 会将链接 url 中的仓库下载下来并打包为 tar 文件,文件包命名格局为:

[Name]-[Version].[commit_timestamp].tar

其中,[commit_timestamp]为 commit 十六进制工夫戳。

可选参数:

  • filename 定义打包后文件的 Name,默认为 git 仓库名。
  • versionprefix 定以打包后文件的 Version 格局,默认为以后十进制工夫戳。

在 OBS 官网服务器中,tar_scm 服务因为在空间利用率上体现不佳,已被 obs_scmtar 服务取代,但 openEuler 的外网 OBS 临时还不反对obs_scm,所以这里抉择 tar_scm

详见:链接

第二个服务:extract_file

extract_file 能够从 tar 包中提取文件,具体须要提取什么文件取决于 git 仓库中的文件格式。

一般来说咱们能够将打包须要的内容分为四大类:

  • 源码:参加编译过程的文件
  • spec 文件:领导如何打包的标准文件
  • patch 文件:批改源码的差别文件
  • 源文件:不参加编译但须要打包的文件

对于 git 仓库 来说,个别会将所有文件放到仓库的根目录。

此时咱们须要将 spec 文件、patch 文件、源文件 提取进去,源码 则留在 tar 包中期待之后的服务将其压缩打包。

对于 OBS 仓库 来说,为了不便 OBS 零碎应用,人们曾经对源码进行压缩打包。

此时咱们须要将 所有文件 提取进去并省略之后的压缩打包环节。

参数:

  • archive 定义提取起源文件格式
  • files 定义提取文件类型 留神:存在一个顶层目录,其名称未知,因而文件名应以“*/”结尾

第三个服务:recompress

recompress 会对指定文件进行压缩

参数:

  • compression 压缩格局,可选:none、gz、bz2、xz
  • file 压缩内容

第四个服务:set_version

会将 spec 文件中的 Version 替换为 obs_scm 时的

[Version].[commit_timestamp]

spec 文件中能够以

helloworld-%{version}.tar.xz

格局定位源码包。

期待编译实现

因为应用源服务获取源码,所以编译时须要额定过程与工夫。

当状态显示为 blocked 时,表明源服务正在运行。当源服务运行结束时会失常开始打包过程。

我的参考案例:链接

Source Services 在理论场景中的利用

在 oVirt-SIG 组中,咱们利用了源服务实现代码由 git 到 OBS 的同步。

首先,咱们在 git 仓库中以:spec 文件、patch 文件、源码 tar 包 ** 的格局上传并治理源码。

在 OBS 零碎中建设对应包并以一下格局定义_service 文件:

<services>

<service name=”tar_scm”>

<param name=”scm”>git</param>

<param name=”filename”>ioprocess</param>

<param name=”url”>https://gitee.com/openkylin/i…</param>

</service>

<service name=”extract_file”>

<param name=”archive”>.</param>

<param name=”files”>/</param>

</service>

</services>

因为咱们曾经很好的在 git 仓库中设置了存储格局,此时咱们只需将所有文件下载并提取即可。

在这之后,OBS 零碎会帮忙咱们实现编译与打包的环节。

利用 webhook 使源服务在 git 仓库 push 时触发

在写此文时,OBS 零碎还不反对 gitee 格局的 webhook,所以以下内容为应用 github 仓库实现。

obs 能够创立令牌(token),当令牌被触发时,OBS 会运行源服务。

将网址与令牌增加到 git 仓库的 webhook 列表中,就能够在 git 仓库中实现触发源服务,进而更新 OBS 中的包版本。

具体步骤:

创立专属包的 OBS Token(OBS 令牌):

osc token –create <PROJECT> <PACKAGE>

命令将生成仅对 Project/Package 失效的 token。

  • 应用命令 osc token 能够查看以后失效的令牌列表。
  • 应用命令osc token --delete 能够删除令牌

关上 git 仓库网址(以 github 为例):

关上仓库 -> Setting -> Webhooks

点击左上方的 Add webhook。

在 Payload URL 中以:

http://openeuler-build.huawei…; 令牌 ID>

为格局填入。

在 Secret 中填入令牌秘匙,按需要抉择 trigger 类型,保障 Webhook 为 Active 状态。

之后点击 Add webhook 即胜利实现。

可尝试触发 trigger 以验证成绩。


增加小助手 openEuler,退出 openEuler 交换群

更多内容,敬请关注 openEuler 公众号

正文完
 0