Mozilla 開發人員的強力小幫手 – Autolander

有在關注謀智台客的朋友們,應該都知道 Firefox OS (B2G) 是由 Gaia、Gecko、Gonk 所組成。透過『我也想成為 mozillian!教你如何貢獻到 mozilla code base』我們對如何貢獻到 Gecko 的部分有了一定程度的了解,正因為 B2G 的 Gecko 是放在 Mozilla 的 hg 伺服器 (https://hg.mozilla.org),而非 GitHub [註1],因此需要由警長幫忙將通過測試與審核的 patch (es) 手動 land 到 Mercurial Gecko repository。然而,對於 B2G 非 Gecko 的專案,例如:放在 GitHub 的 Gaia,在處理上會有什麼不同呢?本文將以在 Firefox OS (B2G) 同樣扮演重要角色,負責使用者介面與應用程式的 Gaia 為例,為各位介紹 Mozilla 開發人員的強力小幫手 – Autolander。

  • [註1] GitHub 上的 gecko-dev 只是放在 Mozilla hg 的 Gecko 的鏡像 (mirror),所以我們無法對該 repository 送出 Pull Request。

什麼是 Autolander?

一般而言,要貢獻到 mozilla code base 需要經過認養 bug、製作 patch、送交審核、通過測試等步驟,最後才能順利貢獻。我們會需要經常上 Bugzilla 檢查審核結果,修改 patch,重新 commit,再對新的 patch 送出新的審核申請與自動測試,在這個繁複的工作流程中,牽扯到 Bugzilla、GitHub、Treeherder 等多個元件的反覆切換,不少動作其實可以自動化完成,所以 Mozilla 將這些工作流程整合,並交由一個機器代理人 (bot) 自動化處理這些雜事。這個代理人讓開發人員盡量專注在解決 bug 上,無需分心在其他事物,就像是超級秘書一樣,這個超級秘書、強力小幫手,我們稱它叫 Autolander。

如何使用 Autolander?

Step 1:在 GitHub 上建立 Pull Request

這邊依個人習慣可能做法會有所不同,筆者僅分享自己的做法給各位參考,如果本身常常在 GitHub 與人協作,熟悉建立 Pull Request 的方法,可以直接跳過前往 Step 2。

以筆者之前解過的 Bug 1139265 為例,通常在認養 bug 之後,筆者會去 pull 最新版的 code:

接下來,建立一個 branch 來存放解 bug 的 patch,筆者習慣用 bug number 來命名,比較好管理:

接著,我們針對 bug 做了一些修改,並將改好的 patch 送出 commit:

注意,commit message 一定要有正確的 bug number,否則 Autolander 將無法作用。關於如何寫出符合一般 convention 的 commit message 可以參考 Mozilla Committing Rules。接下來,我們在 GitHub 上找到 Gaia repository,按下位於右上角的 Fork 按鈕,fork 一份到自己的 GitHub:

Screen Shot 2015-05-08 at 3.47.39 PM

回到自己的 GitHub 應該可以看到成功 fork 的 Gaia repository:

Screen Shot 2015-05-08 at 4.16.55 PM

回到自己電腦,替這個 fork 建立 remote link,remote repository URL 可以在 GitHub 頁面右側的 clone URL 找到:

接下來,把 local 改動的 branch push 到剛剛 link 好的 remote fork repository。

這時回到 GitHub 重新整理頁面,可以看到剛剛 push 上去的 branch (branch: bug1139265),切換到該 branch 並點下左邊的 create a pull request 完成建立 Pull Request。

Screen Shot 2015-05-08 at 5.02.55 PM

Step 2:Autolander 自動介入幫忙

這時,Autolander 會自動介入做兩個動作。首先,Autolander 會將 Pull Request 的連結自動附加到 Bugzilla 上對應 bug number 的附加檔案:

Screen Shot 2015-05-08 at 5.14.16 PM

注意的是,如果在 Step 1 的 commit message 中,bug number 沒有正確輸入,Autolander 將會找不到正確的 bug 導致附加檔案的功能失敗。接著,Autolander 將 Pull Request 上的改動,hook 到 Treeherder 開始跑自動化測試,並提供測試結果連結:

Screen Shot 2015-05-08 at 5.17.45 PM

Step 3:回到 Bugzilla 設定審核 (review) 請求

這時,我們可以回到 Bugzilla 的頁面,對 Autolander 自動附加的檔案連結,設定 r? 以提出審核請求。切記,指定的 reviewer 必須是 suggested reviewer 之一,否則可能導致 Autolander 失效。

Screen Shot 2015-05-08 at 5.40.20 PM

Step 4:回到 Bugzilla 設定 checkin-needed 請求

如果 patch 得到 r+,自動化測試結果也沒有任何錯誤,我們可以再回到 Bugzilla 頁面,在 Keywords 欄位設定 checkin-needed:

checkin_needed

這時 Autolander 會做幾個基本檢查,確認是否符合以下條件:

1. Bugzilla 上 Pull Request 的附加檔案連結得到 r+,且給予 r+ 的成員是 suggested reviewer 成員之一。

2. Pull Request 被 hook 到 Treeherder 上的自動化測試全部成功,沒有任何錯誤。

只要同時符合以上兩個條件,且該 bug 的 Keywords 被設定 checkin-needed,則 Autolander 會自動完成 land code 動作,並將 bug 設為 resolved:

Screen Shot 2015-05-08 at 5.36.46 PM

總結

透過 Mozilla 開發人員強力小幫手 – Autolander 的幫忙,我們可以專心解決 bug,將開發人員反覆送交測試的時間成本,以及警長人工 land code 的時間成本省下,既能確保完成品質控管的程式碼能在第一時間 land 進 repository,最重要的貢獻在於,讓世界各地的開發人員得以將精力留著去做對 open web 更重要的事。

看完本文,大家是否對於貢獻給 Mozilla 更加躍躍欲試了呢?下次透過 Autolander 的幫忙成功 land code 之後,別忘了跟這位偉大的超級秘書說聲辛苦了。

疑難排解

為何我建立 Pull Request 後,Autolander 沒有 hook 到 Treeherder 跑自動化測試?

有時候可能是 Autolander 過於忙碌而遺漏,可以到 GitHub 上將 Pull Request 關閉重開即可解決。

通常解 bug 建立 patch 的過程肯定會反覆修改,如果 local 端有了新版 patch 該怎麼辦?

這時可以使用 force push 的方式,將 local 端新版的 commit 照樣 push 到 remote fork,Autolander 一樣會將更新的版本 hook 到 Treeherder 跑自動化測試:

參考資料

[1] Submitting a Gaia patch

[2] Using pull requests

您可能也會喜歡

目前找不到相關文章

對此文章發表回應

你的電子郵件位址並不會被公開。 必要欄位標記為 *