我的openEuler社群參與之旅

openEuler是什麼?

openEuler是一個開源、免費的Linux發行版平臺，將通過開放的社群形式與全球的開發者共同構建一個開放、多元和架構包容的軟體生態體系。同時，openEuler也是一個創新的平臺，鼓勵任何人在該平臺上提出新想法、開拓新思路、實踐新方案。

安裝介面：

openEuler的官方網站： http://openeuler.org/

repo 下載地址： http://repo.openeuler.org

文件手冊：http://openeuler.org/zh/docs/20.03_LTS/docs/Releasenotes/release_notes.html

openEuler版本怎麼規劃?

說明：

1. 有創新版本和LTS（Long term support）版本兩條線的版本。

2. 遵循Upstream First原則，軟體帶包直接來源於原生社群，並反哺原生社群。

3. master分支即為當前最新版本開發分支，一旦釋出創新版本或LTS版本，

   即會基於當前master主幹拉出對應版本分支進入維護階段。

openEuler 版本如何構建？

openEuler構建模型：

版本如何構建：

說明：

openEuler 版本里有啥軟體？

最直觀的方式是訪問openEuler官方repo，看看釋出件。

另外一種方式，就是訪問openEuler OBS上的構建工程，可以知道每個版本里包含哪些軟體，當前的構建狀態是啥樣的。

軟體是如何管理的？

openeuler原始碼倉庫管理：

• openEuler所有程式碼託管在gitee.com
• 有openeuler、src-openeuler兩個group
• 都是原始碼化、配置化管理

當前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. 軟體包管理按照軟體包所處的時間點分為：、、。
2. 每個階段的輸入是圓框綠底，如。
3. 所有的開發和維護動作是由issue觸發。issue可分為需求、問題、CVE等型別。。
4. 所有修改和操作通過PR來發起。
5. 全景圖中，每個動作都可能涉及規範或指導。將在後面以表格的方式整理呈現。

全景圖中涉及的規範：

階段	動作	規範或指導
引入
		指導：《如何申請SIG》 --待輸出--
		規範：《軟體包引入和退出要求》 指導：《openEuler加包指導》 --待輸出--
		規範：《軟體包打包規範》
開發&維護
		規範：《軟體包升級選型規範》 --待輸出--
		指導：《軟體包打包規範》
		規範：《軟體包打包規範》 指導：《如何提交PR、發起檢視及合入驗證》 --待輸出--
		規範：《openEuler漏洞處理流程》 規範：《openEuler漏洞嚴重性評估》 指導：《如何申請CVE、漏洞上報》
		規範：《openEuler軟體包隨版本釋出規範》 --待輸出-- 指導：《如何將軟體包加入openEuler釋出版本》--待輸出--
		規範：《安全漏洞處理和釋出流程》
退出
		規範：《軟體包引入和退出要求》

如果參與openEuler社群貢獻？

第一步，開源並不意味者隨心所欲，簽署CLA：“貢獻者許可協議”是第一步，閱讀並遵守openEuler社群的行為守則；

第二步，從瞭解、安裝、使用、測試openEuler開始，積極反饋問題和建議，相關的文件和手冊，以及相關的資訊可以幫助你更加深入的瞭解openEuler。

第三步，開發者熟悉社群的開發流程後——《貢獻者指南》，可以基於自己感興趣的專案和軟體，在碼雲上openEuler對應的專案提交自己的貢獻。

瞭解gitee工作流

• 準備工作

  安裝GIT、註冊賬號、環境配置、找到感興趣的專案

• Fork倉庫

  

• 克隆到本地

  git clone http://gitee.com/openeuler/kernel
  

• 拉分支

  git checkout -b myfeature
  

• 修改驗證提交

  git add .
  git commit -m "提交原因"
  

• 推送到碼雲

  git push -f origin myfeature
  

• 建立PR

  訪問你的個人主頁，選擇目標分支，點選 + Pull Request 來建立一個PR

  

• 關注程式碼審查意見

  給PR指派檢視人員，及時回覆reviewers的意見。

  

• 更新PR

  碼雲預設會把個人倉庫的分支與目標倉庫的對應分支的差異作為一個PR，所以本地對該分支的修改，當push後，自動會更新到PR中。

建議：

1. 相關的修改，單獨拉分支來修改提交，並建立PR。如果可以，一次commit一個分支。
2. 當PR合入後，可以強制同步最新程式碼到個人倉庫。
3. 不要在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的郵件列表或[email protected]求助。

這裡是一個可供參考的示例。

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，您可以向[email protected]發求助郵件。建議您在郵件列表內用“【開發過程疑問】”作為標題，在內容中寫出你尋找的SIG或專案的特徵，我們會為您提供幫助。

確定好你要建立小組後，可以按照模板建立一個新的sig目錄，並提交 PR 到 community倉庫，並在TC例會上申請議題（訂閱[email protected]，並關注議題收集的郵件），經過大家一致同意後，合入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工程便會觸發構建。

  

• 軟體打包符合打包規範，請參考如何打包。

• 該工程下所有軟體包成功的構建結果，歸檔在：

  

  它是以repo源的方式歸檔，可以直接使用yum安裝。

  

openEuler OBS使用

這兩片文章幫助你瞭解obs的基本使用。如何使用 openEuler OBS - （一）介紹 和如何使用 openEuler OBS - （二）與gitee的聯動

什麼是obs？

OBS是Open Build Service 的簡寫（官方網址：http://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，並寫入以下內容：

   [general]
   apiurl = http://openeuler-build.huawei.com/
   
   [http://openeuler-build.huawei.com/]
   

註冊OBS賬號

開啟 http://openeuler-build.huawei.com/，點選右上角“Sign Up”，註冊自己喜歡的帳號。

註冊完成後，重新回到上面網址。點選右上角的“Login”，用新賬戶登入。系統會在註冊時自動建立一個以“home:使用者名稱”為格式命名的Home Project。

後續需要郵箱向[email protected]申請。

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、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">http://gitee.com/openkylin/ioprocess.git</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.com/trigger/webhook?id=<令牌ID>

為格式填入。

在 Secret 中填入令牌祕匙，按需求選擇trigger型別， 保證Webhook為Active狀態。

之後點選 Add webhook 即成功實現。

可嘗試觸發trigger以驗證成果。

----------------------------------------------------------------------------------------

新增小助手 openEuler，加入openEuler交流群

更多內容，敬請關注openEuler公眾號