openEuler创新版本（非LTS）openEulerLTS版本版本定位构筑开发者生态，新特性活跃，版本演进快支持合作伙伴构筑商业发行版发布周期0.5年2年维护周期0.5年4年ormore质量标准低，对标fedora质量要求中，对标centos质量要求关键工作新特性、bugfix、CVE、升级选型等有限特性、bugfix、CVE对应分支当前无，下一个版本openEuler-20.09最新分支openEuler-20.03LTS
openEuler构建模型：
版本如何构建：
最直观的方式是访问openEuler官方repo，看看发布件。
另外一种方式，就是访问openEulerOBS上的构建工程，可以知道每个版本里包含哪些软件，当前的构建状态是啥样的。
openeuler源码仓库管理：
openeuler/community仓库下，以下三个文件比较重要：
通过修改这几个文件，来新增、删除软件包仓库，来给相应的软件包划分sig，从而实现sig的owner对软件包的权限管理。
SIG就是SpecialInterestGroup的缩写，openEuler社区按照不同的SIG来组织，以便于更好的管理和改善工作流程。
openEulerSIG维护策略
上图是openEuler社区开发指引图。
全景图中涉及的规范：
阶段动作规范或指导引入
指导：《如何申请SIG》--待输出--
规范：《软件包升级选型规范》--待输出--
规范：《openEuler软件包随版本发布规范》--待输出--指导：《如何将软件包加入openEuler发布版本》--待输出--
建议：
包括但不限于：
结合前面的开发者全景图，可以分解成以下动作：
注意事项：
检视代码:
对于贡献者，为了使您的提交更容易被接受，您需要：
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-->SIG是否存在
SIG是否存在-->创建SIG兴趣小组:不存在
SIG是否存在-->对应SIG下添加仓库:存在
对应SIG下添加仓库-->评审合入
评审合入-->[*]
当前发现openEuler社区缺少你需要的软件时，你可以尝试动手为社区贡献软件包。这里不再赘述OS是如何由linux软件包组成的，以及如何制作一个rpm包。这里着重讲解贡献软件包的流程。
原本是作为发行版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格式。
方便测试框架、构建工程调用。
安装osc
这里以Fedora30为例：
执行dnfinstallosc命令安装osc。
配置openEuler的OBS
有很多方法可以将osc链接至openEuler外网的OBS：
注册OBS账号
oschelp是帮助指南。类似git命令。
ListExistingContentontheServer
oscls#listprojects
osclsApache#listpackagesinaproject
osclsApacheflood#listfilesofpackageofaproject
CheckoutContent
osccoApache#entireproject
osccoApacheflood#apackage
osccoApachefloodflood.spec#singlefile
UpdateaWorkingDdirectory
oscup
oscup[directory]
oscup*#fromwithinaprojectdir,updateallpackages
oscup#fromwithinaprojectdir,updateallpackagesANDcheckoutallnewlyaddedpackages
UploadChangedContent
oscci#currentdir
oscci[file1][file2]#onlyspecificfiles
oscci[dir1][dir2]...#multiplepackages
oscci-m"updatedfoobar"#specifyacommitmessage
ChecktheCommitLog
osclog
Showthestatus(whichfileshavebeenchangedlocally)
oscst
oscst[directory]
Ifanupdatecannotbemergedautomatically,afileisin'C'(conflict)state,andconflictsaremarkedwithspeciallines.Aftermanuallyresolvingtheproblem,useoscresolved*FILE*.
MarkfilestobeAddedorRemovedontheNextCheckin
oscaddfoo
oscrmfoo
AddallNewFilesinLocalCopyandRemovesallDisappearedfiles
oscaddremove
Generateadifftoviewthechanges
oscdiff[file]
ShowtheBuildResultsofthePackage
oscresults
oscresults[platform]
ShowtheLogFileofaPackage
(youneedtobeinsideapackagedirectory)
oscbuildlog[platform][arch]
在本地机器上构建
oscbuild[platform][arch][specfile][--clean|--noinit|...]
以abuild用户进入chroot环境，方便调试
oscchroot[platform][arch]
配置Project
两种方法：网页操作、命令行操作
在obs主页点击右上角
依次进入HomeProject->Repositories->AddfromaDistribution。
按上图所示填写基础配置，并在Name栏填写喜欢的名字。
在选择后后退至Repositories界面，可以看到如下图所示的环境：
执行命令：oscmetaprj-e[project名]，会看到类似如下文本：
其中，1.repository标签为仓库标签，可添加此项添加编译时的基础环境2.Path标签为可用包路径标签，需手动添加发行版包路径。如需要额外依赖，也可以单独添加。3.Arch标签为编译架构，可同时添加多个。
例如：
`xml
`
新建包
进入Project目录：cd[project名]
新建Package：oscmkpac[package名]
进入Package目录并将下载源码以【tar包、所有patch、spec文件、其他source文件】格式放置：
向新创建的package中添加以上文件：oscadd*
将更改上传至服务器：osccommit
在这里可以注明本次上传的简短介绍，用:wq保存并退出
之后就可以在网页上等待编译并查看结果了。
查看包状态与下载包
您可以在Project与Package主页右侧看到当前编译状态
您可以点击_编译平台->Gotodownloadrepository_到达编译仓库，获得此Project的repo源与所有编译成功的package。
更新包
进入project文件夹：cd[project名]
更新本地代码为最新代码：oscup
进入package目录，使用oscadd命令将新文件添加到package，修改spec文件后使用osccommit命令上传新版本。
分为两部分：
源服务就像是系统中的函数，我们可以通过运行脚本调用它；而脚本就是Package中的_service文件。
创建使用源服务的Package
编辑_service文件
最基础的_service文件将会如下所示：
最外层为标记，在内则为一个个函数，而则为``函数的参数。
为了实现“利用源服务直接获取git源码并编译成包”这个目标，
我们的_service应该类似于这样（以下格式请根据具体情况选择合适的顺序）：
下面将对所需的服务逐一进行介绍：
tar_scm会将链接url中的仓库下载下来并打包为tar文件，文件包命名格式为：
可选参数：
在OBS官方服务器中，tar_scm服务由于在空间利用率上表现不佳，已被obs_scm、tar服务取代，但openEuler的外网OBS暂时还不支持obs_scm，所以这里选择tar_scm。
extract_file可以从tar包中提取文件，具体需要提取什么文件取决于git仓库中的文件格式。
一般来说我们可以将打包需要的内容分为四大类：
对于git仓库来说，一般会将所有文件放到仓库的根目录。
此时我们需要将spec文件、patch文件、源文件提取出来，源码则留在tar包中等待之后的服务将其压缩打包。
对于OBS仓库来说，为了方便OBS系统使用，人们已经对源码进行压缩打包。
此时我们需要将所有文件提取出来并省略之后的压缩打包环节。
参数：
recompress会对指定文件进行压缩
会将spec文件中的Version替换为obs_scm时的
[Version].[commit_timestamp]
spec文件中可以以
helloworld-%{version}.tar.xz
格式定位源码包。
等待编译完成
当状态显示为blocked时，表明源服务正在运行。当源服务运行完毕时会正常开始打包过程。
SourceServices在实际场景中的应用
首先，我们在git仓库中以：spec文件、patch文件、源码tar包**的格式上传并管理源码。
在OBS系统中建立对应包并以一下格式定义_service文件：
由于我们已经很好的在git仓库中设置了存储格式，此时我们只需将所有文件下载并提取即可。
在这之后，OBS系统会帮助我们完成编译与打包的环节。
在写此文时，OBS系统还不支持gitee格式的webhook，所以以下内容为使用github仓库实现。
obs可以创建令牌（token），当令牌被触发时，OBS会运行源服务。
将网址与令牌添加到git仓库的webhook列表中，就可以在git仓库中实现触发源服务，进而更新OBS中的包版本。
具体步骤：
创建专属包的OBSToken（OBS令牌）：
osctoken--create
命令将生成仅对Project/Package生效的token。
打开git仓库网址（以github为例）：
打开仓库->Setting->Webhooks
点击左上方的Addwebhook。
在PayloadURL中以：
为格式填入。
在Secret中填入令牌秘匙，按需求选择trigger类型，保证Webhook为Active状态。
之后点击Addwebhook即成功实现。
可尝试触发trigger以验证成果。
添加小助手openEuler，加入openEuler交流群
openEuler是由开放原子开源基金会（OpenAtomFoundation）孵化及运营的开源项目