131
edits
Building Firefox/SURF: Difference between revisions
→Building and Testing in Mozilla Infrastructure
| Line 27: | Line 27: | ||
<i>Note that all try runs are public, and presently Mozilla does not have a mechanism to do private builds or test runs.</i> | <i>Note that all try runs are public, and presently Mozilla does not have a mechanism to do private builds or test runs.</i> | ||
The <tt>TryServer</tt> is a way to submit a | The <tt>TryServer</tt> is a way to submit a one or more patches and have them built on multiple Operating Systems, run tests, and download builds and logs. Because the entire build system is specified <i>in the mozilla-central tree as configuration files</i> it is possible to write a patch that changes the compiler used (either to a different version, or actually patching the compiler), have the tryserver check out the compiler source from a remote repository, build the compiler, and then use the compiler to build Firefox. All in the cloud. https://wiki.mozilla.org/ReleaseEngineering/TryServer has more information about the TryServer, but we will aim to have a functional quickstart tutorial in this document. | ||
=== Getting Access === | === Getting Access === | ||
| Line 42: | Line 42: | ||
* Talos tests (which are performance tests) are expensive because they run on native hardware (Android, Windows, and OSX especially so) and need to be retriggered multiple times. | * Talos tests (which are performance tests) are expensive because they run on native hardware (Android, Windows, and OSX especially so) and need to be retriggered multiple times. | ||
A good rule of thumb is to get thing working with linux64 debug builds (running the full unit test suite is generally fine) and after that works; move on to building and running optimized builds and unit tests on OSX and Windows. Until you are ready to measure performance, we ask you omit Talos jobs. Unless your research is specifically related to Android (and we would request you tell us that ahead of time) - we ask you not to run Android jobs. | A good rule of thumb is to get thing working with linux64 debug builds (running the full unit test suite is generally fine) and after that works; move on to building and running debug+optimized builds and unit tests on OSX and Windows. Until you are ready to measure performance, we ask you omit Talos jobs. Unless your research is specifically related to Android (and we would request you tell us that ahead of time) - we ask you not to run Android jobs. | ||
=== Your First Try Run === | === Your First Try Run === | ||
| Line 50: | Line 50: | ||
# Ensure that ssh is properly configured with the ssh key you created during your commit access process (e.g. using ssh-agent + ssh-add, or editing .ssh/config) | # Ensure that ssh is properly configured with the ssh key you created during your commit access process (e.g. using ssh-agent + ssh-add, or editing .ssh/config) | ||
# Create a test commit | # Create a test commit | ||
# Ensure your working directory is clear (that you have have no modified files with <tt>hg status</tt>. | # Ensure your working directory is clear (that you have have no modified files with <tt>hg status</tt>). | ||
After that there are multiple ways to push to try; but the two most common are: | After that there are multiple ways to push to try; but the two most common are: | ||
| Line 62: | Line 62: | ||
Fuzzy allows you to very selectively choose what tasks to run. [https://firefox-source-docs.mozilla.org/tools/try/selectors/fuzzy.html Its documentation is located here.] It will automatically figure out dependencies; so if you choose to only run linux64-mochitests, it will schedule the needed linux64 build job as well. | Fuzzy allows you to very selectively choose what tasks to run. [https://firefox-source-docs.mozilla.org/tools/try/selectors/fuzzy.html Its documentation is located here.] It will automatically figure out dependencies; so if you choose to only run linux64-mochitests, it will schedule the needed linux64 build job as well. | ||
Once you have pushed using <tt>./mach try fuzzy</tt> once; <tt>./mach try again</tt> will submit the configuration of the last push. | Once you have pushed using <tt>./mach try fuzzy</tt> once; <tt>./mach try again</tt> will submit the configuration of the last push. Fuzzy has lots more [https://firefox-source-docs.mozilla.org/tools/try/selectors/again.html additional options]. | ||
==== Legacy Try Syntax ==== | ==== Legacy Try Syntax ==== | ||
| Line 70: | Line 70: | ||
<pre>./mach try -b do -p linux64 -u all -t none</pre> | <pre>./mach try -b do -p linux64 -u all -t none</pre> | ||
* -b means 'build type' and valid values are 'd', 'o', or 'do' and stand for 'debug' and 'optimized' | * -b means 'build type' and valid values are 'd', 'o', or 'do' and they stand for 'debug' and 'optimized'. | ||
* -p means 'platform'. The most commonly used values are 'linux' (meaning x86), 'linux64', 'win32', 'win64', and 'macosx64'. They are separated by commas, no spaces. | * -p means 'platform'. The most commonly used values are 'linux' (meaning x86), 'linux64', 'win32', 'win64', and 'macosx64'. They are separated by commas, no spaces. | ||
* -u means 'unit tests'. If you are using this syntax you would typically choose either 'all' or 'none' | * -u means 'unit tests'. If you are using this syntax you would typically choose either 'all' or 'none' | ||
| Line 87: | Line 87: | ||
=== Viewing your try run === | === Viewing your try run === | ||
After you submit your try run, it will give you a link that looks like https://treeherder.mozilla.org/#/jobs?repo=try&revision=2827e91340e5b62da31628d8f27546e3a7d53d82 (this link may not work after this job ages out of try; but https://treeherder.mozilla.org will show | After you submit your try run, it will give you a link that looks like https://treeherder.mozilla.org/#/jobs?repo=try&revision=2827e91340e5b62da31628d8f27546e3a7d53d82 (this link may not work after this job ages out of try; but https://treeherder.mozilla.org will show a view of lots of recent jobs. | ||
Here's a quick overview of the most commonly used features. | |||
[[File:Treeherder-job-view.png|frameless|center]] | |||
Here's what the red numbers mean: | |||
# Here is the list of commits in your push to try. '''Note''': Only *new* commits never seen by the try repository are listed here. So if you send a job to try with Commit A, and then a subsequent job with a new Commit B - you will only see Commit B listed. If you `hg histedit` and edit A, then submit again - you will see commit A' (the edited commit A) and commit B' (B wasn't edited, but it has a new parent so it becomes B'.) | |||
# This is the job view. If you send a lot of builds and tests up, this can get pretty crowded. Mouse over things to get a tooltip for what they are. +6 means a group containing 6 sub-items. Build jobs begin with '''B''', and typically the 'normal' Build for this platform will just be a plain B. Here we've selected the Linux x64 Debug Build Job. It's caused a pane at the bottom to open. | |||
# There are two ways to view logs from a job. The Log icon that is below and slightly to the left of the (3) icon - this log view is a web-based reader that is fast to load. The icon directly below the (3) takes you to the full, raw log. I prefer this log personally, even if it takes 45 seconds to load. | |||
# The ... menu directly below the (4) contains an option to "Create an Interactive Task". This lets you connect to the build job and, if it fails, take a look at the error and poke around the system to see what might have gone wrong. Very handy. | |||
# If you select the Job Details tab on a Build ob, you'll see a list of files here like (5). Here you can download your build. It will be in a archive named 'target'. Other built objects - like tests - will be target.foo archives. | |||
==== Adding stuff to a Try Run, or re-running jobs ==== | ==== Adding stuff to a Try Run, or re-running jobs ==== | ||
If you have an existing try run that you want to add jobs to (for example additional build jobs, or to re-run tests) this can be done from the treeherder web interface without needing to send in a new try job. | If you have an existing try run that you want to add jobs to (for example additional build jobs, or to re-run tests) this can be done from the treeherder web interface without needing to send in a new try job. The option to do this is behind the downward-facing arrow, at the top of the treeherder UI on the left-hand side, next to 'View Tests' and the pin icon. | ||
For example, if you want to see if a test always fails, or only some of the time, you can re-trigger the test on an existing job, rather than submit a whole new try push that will perform a build step also. | For example, if you want to see if a test always fails, or only some of the time, you can re-trigger the test on an existing job, rather than submit a whole new try push that will perform a build step also. To retrigger a job, select it in the UI (so its details show up in the bottom pane) and press the 'r' key. It's a shortcut. Pressing the '?' key will show you the shortcut list. | ||
For another example, if your build and tests worked successfully for one platform; and you want to test a second one - you can add the tests on the web interface. This has the advantage of keeping all your results for a single patchset in one place. See [https://wiki.mozilla.org/ReleaseEngineering/TryServer#Scheduling_jobs_with_Treeherder Scheduling jobs with Treeherder] and [https://wiki.mozilla.org/ReleaseEngineering/TryServer#Scheduling_jobs_with_Treeherder_.28Search.29 Scheduling jobs with Treeherder (Search)]. | For another example, if your build and tests worked successfully for one platform; and you want to test a second one - you can add the tests on the web interface. This has the advantage of keeping all your results for a single patchset in one place. See [https://wiki.mozilla.org/ReleaseEngineering/TryServer#Scheduling_jobs_with_Treeherder Scheduling jobs with Treeherder] and [https://wiki.mozilla.org/ReleaseEngineering/TryServer#Scheduling_jobs_with_Treeherder_.28Search.29 Scheduling jobs with Treeherder (Search)]. | ||
The only caveat to this method is that it can be easy to add tests that are not typically run in a normal try run and may currently be failing in general - independent of your patchset. So keep that in mind if you get unexpected failures. | The only caveat to this method is that it can be easy to add tests that are not typically run in a normal try run and may currently be failing in general - independent of your patchset. So keep that in mind if you get unexpected failures. | ||
== Frequently Asked Questions == | == Frequently Asked Questions == | ||