个人 openEuler 社区参与之旅

时间  2021-02-15
标签 html linux ios git github golang web docker centos 安全 栏目 HTML 繁體版
原文   原文链接

openEuler是什么?

openEuler是一个开源、免费的Linux发行版平台，将经过开放的社区形式与全球的开发者共同构建一个开放、多元和架构包容的软件生态体系。同时，openEuler也是一个创新的平台，鼓励任何人在该平台上提出新想法、开拓新思路、实践新方案。html

安装界面：linux

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

repo 下载地址： https://repo.openeuler.orggit

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

openEuler版本怎么规划?

说明：golang

  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.03LTSweb

openEuler 版本如何构建？

openEuler构建模型：docker

版本如何构建：centos

说明：安全

名字说明备注码云 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. 、

  1. 。
  2. 每一个阶段的输入是圆框绿底，如

  1. 。
  2. 全部的开发和维护动做是由issue触发。issue可分为需求、问题、CVE等类型。

  1. 。
  2. 全部修改和操做经过PR来发起。
  3. 全景图中，每一个动做均可能涉及规范或指导。将在后面以表格的方式整理呈现。

全景图中涉及的规范：

阶段动做规范或指导引入

指导：《如何申请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并修复它
  • 上报漏洞及漏洞处理
  • 提出一些建议，包括不限于网站改进、文档改进、流程规范改进、体验提高等。
  • 为社区添加新的软件
  • 发起社区新项目

结合前面的开发者全景图，能够分解成如下动做：

一、建立issue，提交需求&问题&建议

  • 提出问题：若是您发现并想向社区上报问题或缺陷，问题提交的方式就是建立一个Issue。您只要将问题以Issue的方式提交到该项目Repository的Issue列表内，并查看Issue提交指南以获取更多的信息。提交问题时，请尽可能遵照问题提交准则。
  • 提出建议：若是您想对SIG领域内贡献出本身的意见或建议，也能够经过提交Issue的方式分享给你们。你们能够在该Issue上充分的交流和讨论。为了吸引更普遍的注意，您也能够把Issue的连接附在邮件内，经过邮件列表发送给全部人。
  • 提出需求：若是你但愿某个特性或是技术在openEuler上落地，能够提交需求类issue，清晰完整的描述有助于团队成员理解，并被更快的接受和排入开发计划。

二、提交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求助。

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

三、建立兴趣小组

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等信息。

四、贡献软件包

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_scm、tar 服务取代，但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、bz二、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公众号

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程