Once you have setup the environment, the workflow could be still based on git, and most thing are dealt automatically. Mozilla is a pretty open workplace so I can share my workflow with the world. Here are a reference about how I did for per patch/weekly/per setup/one time workflow.
Per patch workflow
When I work on a new bug, I'll checkout a new branch (on mac)
$ git checkout -b bugxxxxxxx inbound/branches/default/tipor (on ubuntu)
$ git checkout -b bugxxxxxxx inbound/defaultUsually the bug is focus on a component of gecko, such as `browser/components/customizableui`. To make .js/.jsm changes work, we don't need to rebuild gecko. But to make some C++ code or new test code works, we need to rebuild this part of source via
$ ./mach build browser/components/customizableui
Once we have some progress for the patch, we can test code via command:
$ ./mach test browser/components/customizableui/testOnce the patch is ready, commit it as normal git commit, with a structured syntax:
`Bug xxxx - description. ;r=?reviewer_bugzilla_alias`.
Then, use git mozreview command to push the commit onto bugzilla for review.
$ git mozreview pushOoh, you also need to make sure you've followed the JS code style https://wiki.mozilla.org/DevTools/CodingStandards#Code_style and CSS code style https://wiki.mozilla.org/Firefox/CSS_Tips
You can use try chooser http://trychooser.pub.build.mozilla.org/
to select test suites that runs automatically on the test server. Treeherder is Mozilla's test server hosted on AWS (Amazon Web Service). Push code there and everyone will have the same base to validate if your code works well on anyone's computer.
The reference try script (credit from :Gijs) for `browser/component` is
try: -b od -t none -p win32,win64,macosx64,linux,linux64,linux64-asan -u mochitest-bc,mochitest-e10s-bc,marionette,marionette-e10s
You can manipulate the script based on what you need to test.
Because build takes more time, I usually do the following command only twice a week if necessary.
We need update gecko repository regularly:
$ git remote update
Checkout a new bug and then rebuild the stack
$ ./mach build
The command will compile the whole gecko.
Do at every Setup
You may check MDN as a start point, with Developer Guide https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide and especially the source code page
I will do the setup flow everytime I got a new laptop.
1. Update git
Use the PPA from the maintainers of
$ sudo apt-add-repository ppa:git-core/ppa
$ sudo apt-get update
$ sudo apt-get install git
2. Install git-cinnarbar
gecko itself managed via mercurial, we need install git-cinnarbar to help us deal with mercurial codebase via git.
$ sudo apt-get install mercurialThen set git-cinnabar into system PATH
$ git clone https://github.com/glandium/git-cinnabar.git
$ gedit ~/.bashrc
$ . ~/.bashrc
Then followMozilla: A git workflow for Gecko development to checkout gecko via git.
Make sure you follow the firefox build guide https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build to setup firefox build environment.
install style check related libraries via following command:
$ ./mach eslint --setup
You may want install mozreview which is improve the overall experience of review with Bugzilla http://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview/install.html
~/.mozbuild/version-control-tools`. We need update system PATH
version-control-tools into `
$ gedit ~/.bashrc
Then, run bootstrap script to install required build environment$ . ~/.bashrc$ git config --global bz.username email@example.com
$ git config --global bz.apikey as3r123hj325hjld3$ git config --global mozreview.nickname mynick$ git mozreview configure
$ ./mach bootstrap
Then, the most time saving advice: setup mozconfig for artifact builds if possible.
When you only work for front-end related work (non c++), Artifact build will download compiled platform code to save you lots of build time.
Do One time
Create Bugzilla API key