Mozilla 勉強会＠東京 8th https://dev.mozilla.jp/event/workshop16/

1. Mozillaにおけるビルドインフラ
Makoto Kato / Mozilla Japan

2. Infra service
• Mozilla.org開始時から
• Bug Tracking System (Bugzilla)
• Version Control System (CVS) / Viewer (Bonsai)
• Automation building (Tinderbox)

4. Agenda
• ソースコード管理など
• Automations!
• Building
• Testing
• etc

5. VCS / REPOSITORY

6. Version Control System
• http://git.mozilla.org/
or
https://github.com/mozilla/ for GIT (mirror)
• http://hg.mozilla.org/ for mercurial
• cvs.mozilla.org / cvs-mirror.mozilla.org for CVS
• svn.mozilla.org for subversion

7. VCS history
• mozilla.org設立時はCVS、Firefox 3.5からMercurial
• githubにも現在ミラーが存在 (Mozillaで同期してます)
• B2Gはgithub。B2G上のGeckoはgithubにあるミラーを利
用
• NSPRやNSSは引き続きCVS (GoogleとかRedHatとかが
使ってるし)
• 通常git使って、land時だけmercurial使う人もいる

8. Repositories

9. mozilla-central
• 従来から使われている。通称Trunk
• Nightly
channelで使われるもの。NightlyはPSTの
AM12:00ごろからビルドスタート
• テスト失敗はlandした張本人がケアする必要あり
or ryanvmなど)がmozilla-inboundからマー
• コビトさん(ed
ジしてくれる (Firefox teamは彼らでマージ)

10. mozilla-inbound
• 開発者みんなが主に使ってるレポジトリ
• テストが失敗したかどうかをlandした張本人がケアする必要
がない
• ちょっとしたtypoだと、r=bustageで直すけど
• ビルド or テストがこけたらコビトさん達が問答無用にバックア
ウト
• コビトさん達がm-cにマージしてくれる(1日2回程度)

11. Why Inbound?
• DeveloperのPainを解消する
• 常にテストを成功したかどうかをチェックしないといけない
• Bustageかどうかの確認
• PGO対策 (Compiler Bug?)
• 成功しなければバックアウトされるだけなので、ツリーを監視
する必要なし
• Staff? もういらなくなった

12. Project Repositories
• fx-team … m-cへのマージ用にFirefox teamが利用
• UX … Firefox teamのテスト実装用
• Alder … 現在はWebRTC用
• Elm … 現在はWindows Metro版用
• Ionmonkey … New Baseline JIT用にJavaScript Teamが
使用
• などなど

13. Build automations
• 各プロジェクトごとにビルド設定を決められる
• Nightlyを有効にするかどうか
• ビルドターゲット
• 場合によって、toolchainを変えたりもしてる

14. User Repository
• Level
1権限以上を持つと、hg.mozilla.org/users/<自分
のメアド>に自分専用レポジトリを持つことが可能
• sshでhg.mozilla.orgに入って管理
• https://developer.mozilla.org/en-
US/docs/Creating_Mercurial_User_Repositories

15. Access Permission
• Level 1-3まである
• Level 1 … try server
• Level 2 … Project Repository
• Level 3 … mozilla-central
• Mozillaに入社してもLevel 3もらえない (Level 1だけ)
• ゲットするにはVocheが必要

16. Mercurial hook
• Land時にコメントが正しくない場合はlandを受け付けない仕
組みを導入
• Treeのステータスに応じてコメントフォーマットが決まってる
• Aurora
/ beta などのレポジトリでは、コメントのフォーマット
にa=xxxxがないとlandを受け付けない
• Tree ClosedのときはCLOSE TREEを入れないと受け付け
ない

17. Approval?
• Aurora、Betaなどでは、Approvalがないとチェックインダメ
• Blocking+のFlagがBugzillaについている場合はいらない

18. Checkin-needed
• コミット権限のない人がバグを修正する場合どうするか？
• review+をもらったら、Bugzilla上にcheckin-neededをつけ
るとコビトさん達がlandしてくれます

19. 3rd party source code in m-c
• Firefoxでは他のOSSのライ
ブラリをいろいろ利用
• about:license
• 基本的にはUpstreamへの
修正+*.patchファイルをレ
ポジトリにland

20. Source Code Indexing
• mxr.mozilla.org
• 某ライセンス品をカスタマイズしてる
• mozilla-central
/ mozilla-aurora / mozilla-beta から
Chromiumまでいろいろとインデックス対象
• dxr.mozilla.org
• Mozilla謹製のインデクサ

21. Aside: GAIA/B2G
• GAIAはルールが異なる
• Githubでハンドリング
• http://github.com/mozilla-b2g/gaia/
• Firefox OS v1まではちょっとルールが変更になる
• blocking-basecampものはBugzillaでも管理

22. AUTOMATIONS

23. とある会社の例

28. …

31. Automations
• Automation buildingに使われるもの
• VMWare ESX
• Amazon AWS (for Linux builders)
• Mac mini
• Automation用のインスタンス数は約1500以上

33. Automations
• Automation Testing (additional)
• Windows 7 (nVIDIAのGPU搭載。HWAテスト)
• nVIDIA Tegra 2 Development board
• Pandaboard (B2G)
• etc

35. Target platforms
• Tier 1 (full support and stable release )
• Windows x86 (MSVC10)
• OSX x86 / x86-64 (clang 3.1)
• Linux (GTK+2) x86 / x86-64 (gcc 4.5)
• Android armv6 / armv7 (NDK r5c)
• B2G armv6 (for Telefonica device) / armv7 (Panda)

36. Target Platforms
• Tier 2 (support automation building)
• Windows x64 (Tier 3に格下げ)
• Tier 3 (by not Mozilla?)
• Linux (non-intel) / Linux Qt
• *BSD (OpenBSDの中の人がメンテ)
• OS/2 (ドイツ方面)
• Solaris (Oracle Chinaの中の人がメンテ)

37. Test Target Platforms
• Windows XP / Windows 7
• OSX 10.6 / 10.7 / 10.8
• Linux (Fedora 12)
• Android 2.2
• B2G (based on ICS)

38. Tinderbox

39. Tinderbox
• 要はbuildbot
• 1998年のMozilla.org設立
時に作成されたもの
• Landごとにビルド
• Orange / Red時にはコメン
ト必須
• NPOBとかのコメントを入れ
れば自動ビルドされない

40. Tree Status

41. Tree Status
• Open
• 通常の状態。誰もがland可能
• Closed
• ネットワークトラブル等でland不可能の状態
• CLOSED TREEコメントを入れればland可能
• Approval
• 誰かの許可が必要。a=xxxのログが必要

42. Tbpl (TinderBox Push Log)
• Tinderboxの後継版
• http://tbpl.mozilla.org/
• そもそもはテスト失敗を調べ
るためのツールが正式ツー
ルへ

43. Self service build interface
• 自動ビルドをコントロール
• 自動ビルドが始まった場合
に止めることが可能
• 他人のも可
• 強制clobberやPGO build
やNightly buildのキックも
可能

44. Web Tools
• 今までのものはREST APIとしても提供されている
• tbplもSelf
Service buildもREST API経由でAutomation
Builderにアクセス

45. B2G? GAIA?

46. Machine Assignment
• Automation BuildとAutomation Testは別のマシンが割り
当てられる
• BuildはVM、Testは実際のクライアント
• できる限り並列化！

48. Random Orange
• テストの中でもよく失敗するもの(Random Orangeと呼んで
ます)が結構ある
• マウスとかエディットとかフォーカスとか
• どれがwell-knownかどうかなんて知ってる人しかわからな
い
• Well-knownの場合はコメントを入れること！
• 対応するBuzillaのバグにもコメントを入れる

51. Suggestion for failure

52. New Test failure
• 自分のlandが原因ではないRandom Orangeが発生した場
合は、Bugzillaへバグを登録
• Keywordへintermittent-failureを入れること
• Tbplで自動的に拾ってくれるようになります

53. Try server
• Land前にテストが失敗しないかどうかとかをテストするための
もの
• お試しlanding＋Automation Testingが可能
• 作成したビルドはpublicのFTPサーバーに置かれる
• 数日で削除
• あまりにも便利すぎて、クロ何とかというブラウザの開発にも同
様のものが導入されてます

54. How to use try server
1のチェックイン権限(10から20個くらいのバグの修
• 要Level
正すればもらえる)
• ssh://hg.mozilla.org/tryへ以下のコメントを修正ともにland
するだけ
try: -b do –p all –u all –t none
• Try Chooser
• http://trychooser.pub.build.mozilla.org/

57. Reftest / CrashTest
• 二つのHTMLを比較して”画像的に”正しいかどうかを判断す
るテスト
• 新しいCSSで書いたもの VS 従来のCSSで書いたものとか
• HTMLやXULのRendering Testで利用
• 何とかKitというRendering Engineにも採用されてる

58. MochiTest
• ブラウザ上で動くテストツール
• 主にUIとかchromeなところのテスト
• Chrome権限が必要な場合はSpecialPowersを利用
• https://developer.mozilla.org/en-
US/docs/SpecialPowers
• タイミング依存するテストが多数あるのでよく失敗する (= 自
分の開発環境ですべてパスするのを見ることは稀)

59. MochiTest

60. http.js
• RefTestやMochiTestで利用されるXPCOM baseのHTTP
Server
• 当然JavaScriptで書いてあるので、Firefoxで動かそうと思
えば動くはず
• HTTPヘッダとかも書き換えられます
• サーバーサイドJavaScript (*.sjs) まで

61. JSReftest
• JavaScriptエンジン自体のテスト
• Browser GUI上で動作する
• テスト結果を”コンソール”に出力 (dumpで)

62. xpcshell-test
• コマンドラインで動くXPCOMテスト
• JavaScriptで書く
• UIを利用しない際に使われる
• 主にXPCOMの実装テスト

63. xpcshell-test

64. Unit tests
• make check時に動作する単体テスト
• クロスなビルド環境 (Android / B2G) の場合は実行されな
い
• xpcshell-testで書けないときに用いられる(主にC++)
• Javascriptの単体テストにも利用 (make jit-tests)

65. Marionette
• Re-Implement WebDriver for Firefox
• Also, work on chrome permission!
• B2GのWebAPI用
• B2G Emulator (QEMU) 上でのテスト
• Remote (Cross) Target向け

66. MozMill
• https://developer.mozilla.org/en-US/docs/Mozmill
• PythonでFirefoxやThunderbirdをコントロールしてテスト
• Thunderbirdで標準利用

67. Automation Test
• これだけのテストを実行して、パスしないとバックアウト対象に
なる
• Tier 1はすべてパスしなければいけない！
• 各テストをすべて動かすと約5時間かかるので、並列に実行
して1時間強で終わるようにしてる

69. 手動テスト？
• 自動ではないQA Teamによるテスト項目も存在する
• リリース前のテストとか
• Android版のUIテスト
• MozTrap
• 自動テストでカバーできないもののため
• https://github.com/mozilla/moztrap

70. MozTrap

72. Talos
• Performance Test Suite
• TP5
• Start up time (clean profile / dirty profile)
• Dromaeo
• Memory usages
• etc

73. Talos
• 結果は常にtbpl上から確認可能
• Improve
/ regressionした場合は、
news://news.mozilla.org/mozilla.dev.tree-
management にポストされる
• Performance regression が認められるとバックアウト対象

74. Talos
Improvement! Dromaeo (DOM) increase 2.95% on MacOSX 10.8 Mozilla-Inbound
------------------------------------------------------------------------
Previous: avg 387.749 stddev 4.044 of 30 runs up to revision ab440f162ab8
New : avg 399.169 stddev 1.899 of 5 runs since revision a4c6aedf00de
Change : +11.420 (2.95% / z=2.824)
Graph : http://mzl.la/U77MBy
Changeset range: http://hg.mozilla.org/integration/mozilla-
inbound/pushloghtml?fromchange=ab440f162ab8&tochange=a4c6aedf00de
Changesets: * http://hg.mozilla.org/integration/mozilla-
inbound/rev/a4c6aedf00de
: Bill McCloskey <wmccloskey@mozilla.com> - Backout a6b604916694 (bug
747066) because it's broken
: http://bugzilla.mozilla.org/show_bug.cgi?id=747066
Bugs:
* http://bugzilla.mozilla.org/show_bug.cgi?id=747066 - xpc_UnmarkGrayObject
is slow

75. PERF-O-MATIC
• Graph ServerのWebインターフェイス
• http://graphs.mozilla.org/
• どっかの何とかKitというのにも今年導入されたはず

76. PERF-O-MATIC

77. Telemetry
• ユーザー環境でのパフォーマンスデータ収集のためのツール
• 許可を得てる場合のみ収集
• about:telemetry add-on

78. Telemetry Dashboard

79. AreWe ?
• JavaScript Performance
• http://www.arewefastyet.com/
• Memshrink
• https://areweslimyet.com/
• Package file size
• http://www.arewesmallyet.com/
• Snappy
• http://arewesnappyyet.com/ (coming)

80. Crash analyzing

81. Crash analyzing
• Socorro (Crash reporter)
• https://crash-stats.mozilla.com/
• Firefox 3から導入
• 従来はTalkBackという製品を使用
• Socorroはその解析用サーバー・Webインターフェイスの総
称

82. Client
• GoogleとMozillaでやってるbreakpadを利用
• Breakpadはクラッシュ時に指定されたサーバーへ
minidump形式のファイルを送る
• about:crashesでクラッシュ情報を確認可能

83. BreakPad
• 多数のプラットフォームサポート
• Windows / OSX / Linux / Android / Solaris
• arm / PPC / SPARC / x86 / x86-64
• PTRACEが動かないとAndroidでダンプ取れないけどね！
(SHARP製Androidは無理)
• クラッシュ時にminidump形式のファイルを作成
• スタック上のメモリと各スレッドのコンテキストを保持

84. Server
• Automation
build時にmake buildsymbolsで作成された
シンボル情報(ソースラインと関数名)を蓄積
• Symbol Dumperはbreakpadのソースコードにある
• クラッシュデータが送られたときにそれをもとにスタック情報を
生成
• AndroidでJava内でのUnhandled Exceptionの場合は
AppNoteにログ

85. Automation
• Painが存在するんであればそれを自身で解決する方法を考
えよう
• テストをチェックしないといけないんであれば、できる限りテスト
をチェックしなくてもいいことを！
• 人手がなければ頭を使えばいい！

86. Automation
• 一つの修正だけでも多くのテストを実行してます
• Less Regression!
• Mozillaだけでこんなにテストしてもしょうが無いので将来的に
は、W3Cのための自動テストフレームワークを作ろうって話も
• For compatibility!
• でも手動テストもいる
• これは省きたいと思ってる
• パフォーマンステスト項目もいろいろ追加してる

88. Communications
• We are REMOTE!
• Auckland? London? Mountain View? Paris? San
Francisco? Taipei? Tokyo? Toronto? Vancouver?
• Meetings
• Mailing List
• IRC
• Work Week

89. Meeting
• Weekly Status
• 全体
• Product (Firefox / Android / B2g)
• 製品特化
• Platform (GFX / DOM / GAIA / all / etc)
• Platform Development

92. IRC
• #developers • Mobileバージョン(現在は
Firefox for Androidのみ)
• 全般的な開発むけ 向け
• #introduction • #windev
• Mozillaのコードを触り始め • Windows 版開発者専用
た人向け
• #maildev
• #gfx
• Thunderbird Team用
• GFX / Layout team
• など
• #mobile

93. IRC
• 当然botいます (mozbot/firebot)
• http://ftp.mozilla.org/pub/mozilla.org/webtools/
• firebot:!seen <user name>
firebot: uuid

94. Remote, but…
• WorkWeek
• 各地にいる人が集まって、集中的に仕事する週間
• Vidyo
• ビデオ会議するために導入