== Getting access to the Try Server ==
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]
You can learn more about Mozilla's After you have level 1 commit access policies and start the process , you'll need to do a bit of signing up for an account here: setup before you'll be able to push. See [httphttps://wwwdeveloper.mozilla.org/hackingen-US/docs/committerMercurial/ Becoming a Mozilla ContributorUsing_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'.
== How to push to try Configuration ===== Running a subset of builds/test/talos available to Try===You must use [[Build:TryChooser]] to choose which buildsBefore using try, tests, and talos you would like run on your push to try. Make sure there is some recommended configuration you place the try chooser text in your ''topmost commit''. The [http://trychooser.pub.buildshould set up.mozilla.org/ TryChooser] web page can help you build a commit message for custom requests, so This can the [httpsbe accomplished by running://bitbucket.org/sfink/trychooser mercurial extension]
<pre>% hg qref --message "try: <your $ ./mach mercurial-computed-syntax-here>"% hg push -f try</pre>setup
Where Be sure to at least enable the computed syntax will be something like <code>[http://mozilla-version-b d control-p linux64 tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html firefoxtree extension] and the push-u all to-t none</code>try extension. Please note that running all tests on all platforms The push-to-try extension is very expensive required if you wish to use the |mach try| command (at least 300 compute-hourssee below). Firefoxtree will give you a handy 'try' alias you can use for pushing, and probably overkillprevent you from accidentally pushing multiple heads.If for some reason you prefer not to use firefoxtree, you can set the same alias up manually in your hgrc:
[paths] try === Extending jobs on a push ===We will soon be releasing a version of Treeherder which allows you to add any jobs through the UIssh://hg.mozilla.org/try
To be announcedNote: Never pull from try. You'll end up with hundreds of heads containing everyone's half baked and broken pushes.
=== Pushing to try ===For more information, see [http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/index.html mercurial for mozillians].
To submit your changes == How to push to the try server (assuming they're modifications ==There are two ways to mozilla-central or a similar branch, eschedule jobs on try.g. tracemonkey)You can either push like normal, and select which jobs you have a few options:* <code><nowiki>hg push -f sshwant using [https://hgwiki.mozilla.org/try/<EngineeringProductivity/nowiki><Projects/code> Treeherder treeherder], or* <code><nowiki>hg push -f ssh://<username@host>@hg.mozilla.org/you can specify a try/</nowiki></code> <strike>?</strike> or* <code><nowiki>hg push -f ssh://hg.mozillasyntax in your commit message to schedule jobs automatically.org/try/ -e 'ssh -l <username@host></nowiki></code>
==== Creating an alias =Scheduling jobs with Treeherder ===To save yourself some typing, you can add an alias to your hgrcNote:<pre>[paths]try = ssh://hgThis method does not currently support taskcluster jobs.mozillaSee {{bug|1246167}}.org/try</pre>and then push with<pre>hg push -f try</pre>
==== ~/.ssh/config ====ssh host settings With this method, just push to make life easiertry like you would to inbound (don't create any try syntax):
<pre>Host $ hgpush -f -r .mozilla.org User <commit_user_email_address> IdentityFile ~/.ssh/private_key_file</pre>try
=== Viewing You should see a warning about no jobs being scheduled automatically, followed by a link to your push in treeherder. Open the results ===link, select the drop-down arrow at the top right, and choose "Add new Jobs":
You can see the results of your tryserver build in a number of wayshttps://s3.amazonaws.com/media-p.slid.es/uploads/185196/images/2042414/TH_dropdown.png
* You'll get an email on Click the job symbols you wish to schedule. If you select 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 can have job, the results of your try run posted to bug(s) required build will automatically at the completion of the run using the --post-to-bugzilla flag in your try syntax (see: [[Build:TryChooser]] for examples)* Look for your changeset on [https://treeherder.mozilla.org/#/jobs?repo=try Treeherder]. You can add '''&author=YOUR.EMAIL''' to only see your pushes.* [Obsolete] Compare Talos perf numbers using Pike's [http://github.com/Pike/talos-node talos-node] or mconnor's [http://perf.snarkfest.net/compare-talos/ compare-talos].* Download your completed builds from [httpbe scheduled://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/?C=M;O=D firefox/tryserver-builds on ftp.m.o].
If you're using [https://developers3.mozillaamazonaws.orgcom/enmedia-p.slid.es/Mercurial_Queues Mercurial queues], the <code>push -f<uploads/185196/images/2042426/code> command pushes any patches that are currently applied, and the Try server will build the resultTH_with_jobs. (This is an awesome feature, not a bug!)png
You don’t need to clone or pull from Finally, click "Trigger New Jobs" near the <code>try</code> repo, and you probably don’t want to. You’d get every half-baked changeset anybody ever testedtop right of your push.
See === Scheduling jobs with Try Syntax ===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://blogtrychooser.pub.build.mozilla.com/jorendorff/2008/08/18/push-to-tryorg/ Jorendorff's blogTryChooser] web page can help you build a commit message for more detailscustom requests. It will generate both a syntax string as well as a mach command you can simply paste into your terminal.
==== Using a custom mozconfig mach ====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:
The mozconfigs for recent mozilla $ mach try -central clones are located in the browser/config/mozconfigs directory. Edit those as you please.b o -p linux -u mochitest-1 -t none
If you want to apply The |mach try| command also has some advanced features. It can actually change how the same mozconfig changes job gets run within automation. For example, to multiple platforms, you can edit <tt>build/mozconfig.common.override<run only mochitests under 'dom/tt> instead. This file is included at the end of each of the in-tree mozconfig files.indexedDB':
Android mozconfigs are in mobile $ mach try -b o -p linux -u mochitests --and dom/android/config/mozconfigs.indexedDB
NoteFor more information see:* 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.
== Using a custom Gaia == $ mach try --help
For Gaia-related tests on B2G desktop builds, you can use an arbitrary branch on any github Gaia fork in your try jobNote: This method doesn't work well with mq. To do this, you need to modify $src/b2g/config/gaia.json to point to your repo. Normally, gaia.json looks something like this:
{==== Using the Trychooser Extension ==== "revision"You can also use the [https: "6fbf376b98130fca7198d7d2e5e588cb37dd07c4", "repo_path": "/integration/gaia-central" 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|.
You should edit this file ==== Using mq ====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 include some additional fieldstry manually. First build your try syntax with the [http://trychooser.pub.build.mozilla.org/ TryChooser] web page. Then run:
{ "revision$ hg qref --message "try: "6fbf376b98130fca7198d7d2e5e588cb37dd07c4", "repo_path": "/integration/gaia<your-computed-syntax-centralhere>", "git": { "remote": "", "branch": "", "git_revision": "" } }$ hg push -f try
== Viewing the results ==You must specify remote, and can specify either branch or revision. { "revision": "6fbf376b98130fca7198d7d2e5e588cb37dd07c4", "repo_path": "/integration/gaia-central", "git": { "remote": "https://github.com/jonallengriffin/gaia.git", "branch": "gaia_unit_crash", "git_revision"see the results of your tryserver build in a number of ways: "gaia_unit_crash" } }
When the * You'git' dict in gaia.json is populated in this way, the hg attributes ll get an email on a successful push with a link to treeherder for your revision and repo_path will as well as optional emails on any non-successful build/test/talos results (this setting can be ignored, and adjusted using [[Build:TryChooser]] args for email notification)* You can have the results of your try run posted to bug(s) automatically at the completion of the Gaia run using the --post-to-bugzilla flag in your try syntax (see: [[Build:TryChooser]] for examples)* The link to treeherder will be cloned from printed on the given remote and used command line.* Look for your changeset on [https://treeherder.mozilla.org/#/jobs?repo=try Treeherder]. You can add '''&author=YOUR.EMAIL''' to run the testsonly 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].
== Using a custom gonk-misc ==
You can also specify == Using a custom gonkmozconfig ==The mozconfigs for recent mozilla-misc repository for tests. To do this, you need to edit central clones are located in the file $src/b2gbrowser/config/<target>/sourcesmozconfigs directory. Edit those as you please.xml and then add your remote, for example:
If you want to apply the same mozconfig changes to multiple platforms, you can edit <remote fetch="https:tt>build//githubmozconfig.common.com/walac" name="walac"override</tt>instead. This file is included at the end of each of the in-tree mozconfig files.
After that, you have to modify the gonk-misc project line to point to your repository and the desired revision:Android mozconfigs are in mobile/android/config/mozconfigs.
<project name="gonk-misc" path="gonk-misc" remote="walac" revision="b8fd88760316cbcef261830f4031992fa6c379c6"Note:* 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 then need to commit these changes and push to the may try serverthem, but don't complain if they break.
== Getting debug symbols ==
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.
==Adding new jobs = Debugging with debug symbols === * Windows** Unzip the crashreporter-symbols-full.zip package somewhere, letIt's call it c:\try_symbols** Set your symbol path possible to <tt>cache*c:\symcache;SRVcreate new jobs (or modify existing ones) directly *http://msdl.microsoft.com/download/symbols;SRV*c:\try_symbols</tt> where <tt>c:\symcache</tt> is a writable directory where the debugger can store symbols.*** If using WinDBG, you can type <tt>.sympath ...</tt> with the above path in the command window.*** If using Visual Studioyour try push, provided you can set the <tt>_NT_SYMBOL_PATH</tt> environment variable to the aboveuse taskcluster. (Note that it looks like adding the path to Just edit the unzipped symbols relevant configuration in the Visual Studio settings doesn't work, you really need to add it to the <tt>_NT_SYMBOL_PATH<testing/tt> environment variabletaskcluster. AlsoFor more information on creating jobs, setting a <tt>_NT_SYMCACHE_PATH</tt> environment variable instead of adding <tt>cache*...;</tt> to <tt>_NT_SYMBOL_PATH</tt> doesn't let Visual Studio find the symbols.)*** If see the above approaches don't work for you, an alternative manual approach is described [httpshttp://bugzilladocs.mozillataskcluster.orgnet/show_bug.cgi?id=936784#c69 heretaskcluster docs].* Linux** TODO* Mac** TODO
== Server Status ==
* Try server load can be seen at https://secure.pub.build.mozilla.org/builddata/reports/pending/try.html
* Pending builds by revision are at https://secure.pub.build.mozilla.org/buildapi/pending
* Suggestions for the future can be made [[Build:TryServer:Suggestions|here]] or file a blocking bug against {{bug|try_enhancements}}
=== HOWTO: Preserve a commit message between try pushes ===
Simply create a new patch in your queue for the try attempt commit message.
Future pushes can simply push/pop the try patch onto the applied queue when needed.
<pre>
% hg qref --message "bug xxx - a spell/patch of improvements"
% hg qnew patch.try
% hg qref --message "try: -b o -e -p all -u all -t none"
% hg push -f try
% hg qpop patch.try
</pre>
If you know that your patches commit message is correct you can simply use:
<pre>
% hg qref
% hg qnew patch.try
% hg qref --message "try: -b o -e -p all -u all -t none"
% hg push -f try
% hg qpop patch.try
</pre>
== Other Mozilla Try Servers ==
* [[ReleaseEngineering/ThunderbirdTryServer|Thunderbird Try Server]] for the comm-central repository
* You can push b2g18 to the regular Firefox tryserver, but you will get a lot of oranges. There is currently no work-around. It's possible to eke out some useful information from such a try push -- ask a sheriff, who should be familiar with the expected failures, or otherwise push your qtip rev to try and compare the results to the patched version. Good luck.
== Problem Diagnosis ==
== Buildduty issues ==
=== 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 ask Release Engineering to [[ReleaseEngineering/How_To/Trigger_Talos_Jobs |do a sendchange']], look for someone who is <person>|buildduty use the "Add New Jobs" interface in #releng on IRC. Alternatively you can push again with a different try syntaxTreeherder.
=== How do I cancel existing jobs? ===
