個人 openEuler 社區參與之旅

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. 、

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公衆號