我的openEuler社區參與之旅

語言: CN / TW / HK

openEuler是什麼?

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

安裝界面:

img

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

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

文檔手冊:https://openeuler.org/zh/docs/20.03_LTS/docs/Releasenotes/release_notes.html

image-20200521203551777

openEuler版本怎麼規劃?

image-20200521204342097

img

説明:

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

  2. 遵循Upstream First原則,軟件帶包直接來源於原生社區,並反哺原生社區。

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

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

  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構建模型:

版本如何構建:

image-20200521211038388

説明:

名字 説明 備註
碼雲 openuler Group 這個組織下存放的都是由openEuler社區發起的原生項目,
相當於一個一個的上游社區。例如isula、atune項目。
https://gitee.com/openeuler
碼雲 src-openeuler Group 這裏存放的是以rpm 源碼形式的代碼。每個倉庫源碼都可以直接構建rpm二進制。 https://gitee.com/src-openeuler
OBS open build service,opensuse發佈的一套開源構建系統,類似於koji、yacto等。 https://build.openeuler.org
https://openbuildservice.org
jenkins CI/CD,持續集成平台,主要用於門禁任務、版本構建任務調度等 http://114.116.250.98/
repo 用於歸檔發佈的交付件及yum 軟件源。 https://repo.openeuler.org/

openEuler 版本里有啥軟件?

最直觀的方式是訪問openEuler官方repo,看看發佈件。

發佈件 構建工具 Repo****歸檔地址
ISO:
Dvd ISO 、
Debuginfo ISO
Everything ISO
Source ISO
mkdvdiso(待開源)、 kiwi http://repo.openeuler.org/openEuler-20.03-LTS/ISO
Qcow2鏡像 CreateImage(待開源) http://repo.openeuler.org/openEuler-20.03-LTS/docker_img
容器鏡像 kiwi http://repo.openeuler.org/openEuler-20.03-LTS/virtual_machine_img
LiveCD ?    
   

另外一種方式,就是訪問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:Mainline
LTS版本 openEuler:20.03:LTS LTS版本構建工程,openeuler-20.03-LTS分支代碼   https://build.openeuler.org/project/show/openEuler:20.03:LTS
20.09版本(未拉分支) ---     ---

軟件是如何管理的?

openeuler源碼倉庫管理:

  • openEuler所有代碼託管在gitee.com
  • 有openeuler、src-openeuler兩個group
  • 都是源碼化、配置化管理
group openeuler src-openeuler
定位 代碼倉、原生社區 軟件包倉、製品倉
內容 openEuler發起的原生項目 spec rpm格式歸檔的軟件包倉庫
URL https://gitee.com/openeuler https://gitee.com/src-openeuler
倉庫數量 50+ 2500+
代碼管理 源碼樹 src rpm格式
關係 是src-openeuler的上游社區  

當前openEuler 軟件的管理是以sig組來承載,所有的軟件唯一的歸屬於某個sig。通過sigs.yaml文件,你可以查詢到該軟件屬於哪個sig,並通過sigs專有歸檔目你可以查詢對應的maintainer。只有對應的maintainer才有對應倉庫代碼合入權限。

image-20200521225454468

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社區開發全景?

image-20200506152118205

上圖是openEuler社區開發指引圖。

説明:

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

全景圖中涉及的規範:

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

如果參與openEuler社區貢獻?

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

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

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

瞭解gitee工作流

Gitee-workflow-CopyLink

  • 拉分支

    git checkout -b myfeature
    
  • 修改驗證提交

    git add .
    git commit -m "提交原因"
    
  • 推送到碼雲

    git push -f origin myfeature
    
  • 創建PR

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

    image-20200610173341921

  • 關注代碼審查意見

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

    image-20200610173629091

  • 更新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按鈕,複製倉庫代碼到個人名下。

    image-20200521232246188

  • 將代碼git clone到本地,如果你的修改不涉及二進制源碼軟件包的變化,將所修改的代碼做成一個patch,因為倉庫是以rpm源碼包的格式組織的。

  • 每個PR都會觸發openEuler門禁的檢查,包括不定命名、代碼規範、代碼構建。門禁的結果會稍後回顯在評論中,存在失敗的檢查項要及時修正。

  • 通過門禁中的openeuler-rpm-build的鏈接,你可以逐層找到這次提交構建的臨時rpm二進制。後續會將生成的二進制直接回顯到評論裏。

    image-20200522002832030

    image-20200522003012593

  • 代碼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 --> [*]

image-20200611162154651

	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下添加倉庫 --> 評審合入
    評審合入 --> [*]

image-20200611162225682

當前發現openEuler社區缺少你需要的軟件時,你可以嘗試動手為社區貢獻軟件包。這裏不再贅述OS是如何由linux軟件包組成的,以及如何製作一個rpm包。這裏着重講解貢獻軟件包的流程。

  • 首先,要明確貢獻的軟件包的功能,遵循openEuler軟件包引入和退出原則

  • 再者,由於軟件唯一的歸屬於一個sig,你需要查看當前是否有合適的sig承載,如果沒有,需要你按照步驟3申請成立一個新的sig。

  • 然後,你可以通過提交PR的方式,在對應的sig下添加軟件倉庫。可參考這個提交,一旦審核通過,後台會自動為你在對應的src-openeuler group下創建同名倉庫,並在Factory工程中去創建同名package開始構建,由於默認倉庫裏只有readme,並不會進行真正的構建,而是exclude狀態。

    image-20200522001706202

  • 接着你可以按照2的操作提交一個PR,來上傳可以構建的代碼。一旦合入,Factory工程便會觸發構建。

    image-20200522001826061

  • 軟件打包符合打包規範,請參考如何打包

  • 該工程下所有軟件包成功的構建結果,歸檔在:

    image-20200522002217686

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

    image-20200522002316316

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,並寫入以下內容:

    [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_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/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公眾號