ReleaseEngineering/TryServer: Difference between revisions

m
(Use renamed mach command)
 
(22 intermediate revisions by 9 users not shown)
Line 5: Line 5:
To use the try server, you'll need [http://www.mozilla.org/hacking/commit-access-policy/ Level 1 Commit Access]. You can learn more about Mozilla's commit access policies and start the process of signing up for an account here: [http://www.mozilla.org/hacking/committer/ Becoming a Mozilla Contributor]
To use the try server, you'll need [http://www.mozilla.org/hacking/commit-access-policy/ Level 1 Commit Access]. You can learn more about Mozilla's commit access policies and start the process of signing up for an account here: [http://www.mozilla.org/hacking/committer/ Becoming a Mozilla Contributor]


After you have level 1 commit access, you'll need to do a bit of setup before you'll be able to push. See [https://developer.mozilla.org/en-US/docs/Mercurial/Using_Mercurial#How_do_I_check_stuff_in.3F this guide] for instructions. Assuming you only have level 1 access, you won't be able to push to mozilla-central, but you can replace 'hg.mozilla.org/mozilla-central' with 'hg.mozilla.org/try'.
After you have level 1 commit access, you'll need to do a bit of setup before you'll be able to push. See [https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/auth.html this guide] for instructions.


== Configuration ==
== Configuration ==
Line 22: Line 22:


== How to push to try ==
== How to push to try ==
There are two ways to schedule jobs on try. You can either push like normal, and select which jobs you want using [https://wiki.mozilla.org/EngineeringProductivity/Projects/Treeherder treeherder], or you can specify a try syntax in your commit message to schedule jobs automatically.  
There are a few ways to schedule jobs on try.
 
=== Attach new jobs from the review ===
 
For every patch submitted for review in Phabricator, a new Try run is automatically created. This run is created for static analysis, linting and other tasks.
As described below, attaching new jobs to the run is easy and doesn't require more actions from the developer.
Just click on the ''Treeherder Jobs''.
 
[[File:Screenshot 2019-10-07 ⚙ D48316 Bug 1585593 - Enable Fission for Raptor.png]]
 
For more details, see:
https://firefox-source-docs.mozilla.org/tools/try/index.html#attaching-new-jobs-from-a-review
 
=== Scheduling jobs with Mach Try ===
 
The recommended way to [https://firefox-source-docs.mozilla.org/tools/try/index.html interact with try] is via the command line tool |mach try|. Since try can be used for a wide range of use cases, by developers with varying levels of experience, there is no one size fits all solution when it comes to selecting which tasks to run. Therefore |mach try| offers a range of subcommands called "selectors" for a variety of purposes. To see a list of available selectors, run:
 
  $ mach try --help
 
For deeper information on a given selector, run:
 
  $ mach try <selector> --help
 
If you don't specify a selector/subcommand to try, it will default to using the `syntax` selector. You can change which selector gets used by default by creating ~/.mozbuild/machrc and adding:
 
  [try]
  default=<selector>
 
See [https://firefox-source-docs.mozilla.org/tools/try/selectors/index.html this documentation] for more information on all the available selectors, and [https://firefox-source-docs.mozilla.org/tools/try/presets.html this document] for a list of available presets (derived from [https://searchfox.org/mozilla-central/source/tools/tryselect/try_presets.yml try_presets.yml]).
 


=== Scheduling jobs with Treeherder ===
=== Scheduling jobs with Treeherder ===
Line 46: Line 75:
NOTE: An action task gets scheduled which will schedule all the tasks you chose.
NOTE: An action task gets scheduled which will schedule all the tasks you chose.


=== Scheduling jobs with Try Syntax ===
=== Scheduling jobs with Treeherder (Search) ===
If you know exactly what you want to run, you can use [[Build:TryChooser]] to select which jobs run directly in your commit message. Make sure the commit message containing try syntax is placed in your ''topmost commit''.  The [http://trychooser.pub.build.mozilla.org/ TryChooser] web page can help you build a commit message for custom requests. It will generate both a syntax string as well as a mach command you can simply paste into your terminal.
 
Similar to the above method, there is now an additional way to add jobs to an existing push via Treeherder. Open the push in Treeherder and then choose "Add New Jobs (Search)" from the push's menu:
 
[[File:Add New Jobs Search.png]]


Treeherder will then fetch the list of runnable jobs in the background, then pop up a dialog window listing those jobs:


==== Using mach ====
[[File:Addnewjobssearchinterface.png]]
The recommended way to push with a try syntax, is to use |mach try|. It works with both mercurial and git, and you can use the [http://trychooser.pub.build.mozilla.org/ TryChooser] web page to generate the command. For example:


$ mach try -b o -p linux -u mochitest-1 -t none
At the top of the dialog, there is a search bar. Type part of your desired job name into the search bar and press 'Enter' to filter the list of jobs. (This uses a fuzzy search library, so some minimal typos are allowed). From the filtered list of jobs, select as many of the results as you want (ctrl/shift modifiers work on this list for selecting multiple jobs):


The |mach try| command also has some advanced features. It can actually change how the job gets run within automation. For example, to run only mochitests under 'dom/indexedDB':
[[File:Filteredaddnewjobssearch.png]]


$ mach try -b o -p linux -u mochitests --and dom/indexedDB
Then click the green "Add Selected" button to add the selected jobs to the list of jobs to be run (or click the green "Add All" button to add the entire list of jobs currently in view.


For more information see:
Repeat the filter and selection process until you have all of your desired jobs added to the list. You can remove jobs from the list to be run using the red buttons lower on the dialog if you selected them in error:


$ mach try --help
[[File:Addnewjobssearchselectedjobs.png]]


Note: This method doesn't work well with mq.
When you are happy with your selection, click the blue "Trigger (X) Selected Jobs" button at the bottom of the dialog. Treeherder will send out a request for those jobs to be run, and an action task will be spawned to do all of the behind the scenes magic to make that happen.


==== Using the Trychooser Extension ====
=== Pushing Directly ===
You can also use the [https://bitbucket.org/sfink/trychooser mercurial trychooser extension] from sfink. It has some neat features, like a curses ui that lets you graphically choose a try syntax. Though {{bug|1197868}} tracks implementing this feature in |mach try|. Eventually trychooser will be deprecated in favor of |mach try|.


==== Using mq ====
It's also possible to push to try directly from hg (for now). This might be required if you're using [https://www.mercurial-scm.org/wiki/MqExtension mercurial queues]. In this case, the only way to select tasks is by manually adding try syntax to your commit message:
The aforementioned tools may not play all that nicely with [https://www.mercurial-scm.org/wiki/MqExtension mercurial queues]. If you use mq, you can still push to try manually. First build your try syntax with the [http://trychooser.pub.build.mozilla.org/ TryChooser] web page. Then run:


$ hg qref --message "try: <your-computed-syntax-here>"
  $ hg commit -m "try: -b o -p linux64 -u mochitest"
$ hg push -f try
  $ hg push -f try
 
Using |mach try| is recommended as that will automatically create and cleanup a temporary commit no your behalf, whereas with this method you are responsible for cleaning up any extra commits you make or commit messages you modify.


== Viewing the results ==
== Viewing the results ==
You can see the results of your tryserver build in a number of ways:
You can see the results of your tryserver build in a number of ways:


* You'll get an email on a successful push with a link to treeherder for your revision as well as optional emails on any non-successful build/test/talos results (this setting can be adjusted using [[Build:TryChooser]] args for email notification)
* You'll get an email on a successful push with a link to treeherder for your revision as well as optional emails on any non-successful build/test/talos results
* You can have the results of your try run posted to bug(s) automatically at the completion of the run using the --post-to-bugzilla flag in your try syntax (see: [[Build:TryChooser]] for examples)
* You can have the results of your try run posted to bug(s) automatically at the completion of the run using the --post-to-bugzilla flag in your try syntax
* The link to treeherder will be printed on the command line.
* The link to treeherder will be printed on the command line.
* Look for your changeset on [https://treeherder.mozilla.org/#/jobs?repo=try Treeherder]. You can add '''&author=YOUR.EMAIL''' to only see your pushes.
* Look for your changeset on [https://treeherder.mozilla.org/#/jobs?repo=try Treeherder]. You can add '''&author=YOUR.EMAIL''' to only see your pushes.
* Download your completed builds from [http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/?C=M;O=D firefox/tryserver-builds on ftp.m.o].
* Download your completed builds from [http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/?C=M;O=D firefox/tryserver-builds on ftp.m.o].


== Using a custom mozconfig  ==
== Using a custom mozconfig  ==
Line 90: Line 121:


Android mozconfigs are in mobile/android/config/mozconfigs.
Android mozconfigs are in mobile/android/config/mozconfigs.
If you modify a mozconfig file named <tt>nightly</tt>, please make sure you also change any mozconfig file named <tt>beta</tt> and/or <tt>release</tt> in the same directory, otherwise the test_compare_mozconfigs test will fail.


Note:
Note:
* TryServer purpose is to tell what will happen on Tinderbox, not to check every possible build option/configuration.
* TryServer purpose is to tell what will happen on Tinderbox, not to check every possible build option/configuration.
** Any non-standard feature is implicitly unsupported. You may try them, but don't complain if they break.
** Any non-standard feature is implicitly unsupported. You may try them, but don't complain if they break.
== Re-running tasks with custom parameters from Treeherder ==
It is possible to run a task again, with certain types of changes to its run time environment and parameters. This feature is commonly used to enable debug logging, or run a test repeatedly to reproduce test failures.
In treeherder, select the job you want to re-run (Note: it currently only works for [https://searchfox.org/mozilla-central/source/taskcluster/taskgraph/actions/retrigger_mochitest.py#30-31 some jobs]). The details panel should open. Look for the 3 dots icon ("Other job details") and select "Custom actions...".
[[File:Custom-action.png|thumb|Selecting "Custom Action..." in treeherder.]]
The <tt>retrigger-custom</tt> action is the one selected in the drop-down menu. Modify the task parameters as desired and select "Trigger".
[[File:Custom Taskcluster Job Actions.png|thumb|Treeherder modal to request an action associated to a task]]
This will schedule the task with your specified parameters. The new task will be labeled as <tt>custom-<original_task_name></tt>.
Some of the parameters that you can change are (see screenshot above):
* Environment variables (e.g. <tt>MOZ_LOG</tt>)
* Modify Python's logging level
* Path of the test to execute
* Gecko preferences (think of <tt>about:config</tt>)
* Run a test repeatedly
* Run until the test fails
Common problems:
* By default the entire task is re-run, running all the tests in the original task. If repeat/runUntilFailure is specified, it may take a long time to repeat all the tests, and the log file may be huge. Consider using the path: parameter to limit the run to the test(s) of interest.


== Getting debug symbols ==
== Getting debug symbols ==
NOTE: You might be able to accomplish this by re-running a build task from Treeherder by adding the env variable to the new task.
By default native debug symbols are not uploaded for Try server builds because of their size. If you want to debug your builds locally you must add <tt>MOZ_CRASHREPORTER_UPLOAD_FULL_SYMBOLS=1</tt> to the in-tree mozconfigs. You can do this for all platforms by importing [http://hg.mozilla.org/users/tmielczarek_mozilla.com/mq/raw-file/b44faf6cd177/enable-full-symbols this patch] into your mq and pushing it along with your changes to Try. This will cause a ...crashreporter-symbols-full.zip package to be uploaded to the builds directory for each platform built.
By default native debug symbols are not uploaded for Try server builds because of their size. If you want to debug your builds locally you must add <tt>MOZ_CRASHREPORTER_UPLOAD_FULL_SYMBOLS=1</tt> to the in-tree mozconfigs. You can do this for all platforms by importing [http://hg.mozilla.org/users/tmielczarek_mozilla.com/mq/raw-file/b44faf6cd177/enable-full-symbols this patch] into your mq and pushing it along with your changes to Try. This will cause a ...crashreporter-symbols-full.zip package to be uploaded to the builds directory for each platform built.


Line 175: Line 237:
== CiDuty issues ==  
== CiDuty issues ==  
=== How do I trigger additional talos/test runs for a given try build? ===
=== How do I trigger additional talos/test runs for a given try build? ===
If your trychooser syntax included the tests you'd like more of, then select the job you want on Treeherder and use the + button. For test suites you didn't request originally you can use the "Add New Jobs" interface in Treeherder.
If your syntax included the tests you'd like more of, then select the job you want on Treeherder and use the + button. For test suites you didn't request originally you can use the "Add New Jobs" interface in Treeherder.


=== How do I cancel existing jobs? ===
=== How do I cancel existing jobs? ===
For individual jobs, select the relevant one on Treeherder and use the cancel button. To cancel all jobs, use the menu arrow shown on the header row for each push, and then the "Cancel all" option.
For individual jobs, select the relevant one on Treeherder and use the cancel button. To cancel all jobs, use the menu arrow shown on the header row for each push, and then the "Cancel all" option.
=== TryChooser ===
See the [[ReleaseEngineering/TryChooser#Buildduty_Issues|TryChooser]] wiki page.


== See Also ==
== See Also ==
* https://developer.mozilla.org/en/Creating_Mercurial_User_Repositories
* https://developer.mozilla.org/en/Creating_Mercurial_User_Repositories
* http://trychooser.pub.build.mozilla.org/
* https://wiki.mozilla.org/Sheriffing/How:To:Recommended_Try_Practices
* https://wiki.mozilla.org/Sheriffing/How:To:Recommended_Try_Practices
* https://wiki.mozilla.org/Build:TryChooser
* https://wiki.mozilla.org/ReleaseEngineering:Autoland
* https://wiki.mozilla.org/ReleaseEngineering:Autoland
* [http://build.mozilla.org/buildapi/self-serve Manage Submissions] [[https://build.mozilla.org/buildapi/self-serve/try try]]
* [http://build.mozilla.org/buildapi/self-serve Manage Submissions] [[https://build.mozilla.org/buildapi/self-serve/try try]]
* [https://catlee.github.io/highscores/highscores.html Scoreboard]
* [https://catlee.github.io/highscores/highscores.html Scoreboard]
Confirmed users
1,759

edits