ReleaseEngineering/ThunderbirdTryServer: Difference between revisions

← Older edit

ReleaseEngineering/ThunderbirdTryServer (view source)

Revision as of 12:08, 6 December 2020

558 bytes added , 6 December 2020

note the DTN page is now authorative instead of this one which is obsolete

Mkmelin

129

edits

@@ Line 1: / Line 1: @@
+'''NOTE: this page is obsolete, please refer to <https://developer.thunderbird.net/thunderbird-development/fixing-a-bug/try-server>'''
 == Basic Use ==
-The Thunderbird try server works in exactly the same way to the Firefox try server with a few minor differences. The automation is based on the same hardware and tools, so there should be few differences.
+The Thunderbird try server works in exactly the same way to the [[ReleaseEngineering/TryServer|Firefox try server]] with a few minor differences. The automation is based on the same hardware and tools, so there should be few differences.
 The Thunderbird try server is primarily for building Thunderbird. Whilst building other comm-central apps may work, this is not supported - builds and tests may fail etc.
@@ Line 7: / Line 9: @@
 === Must Read ===
-Please read the [[ReleaseEngineering/TryServer|Firefox Try server page]] to get familiar with the basic workings of try server.
+Please read the [[ReleaseEngineering/TryServer|Firefox Try server page]] to get familiar with the basic workings of try server. Notably, you must have installed the "push-to-try" extension.
 Please also use the [[Build:TryChooser|TryChooser]] whenever possible to limit jobs and save builder time.
 === Differences ===
+Safest bet: Use Mercurial queues, for example:<br>
+<code>hg qnew -m "try: -b do -p macosx64,linux64,win64 -u all" try && hg push -f -r tip cc-try && hg qpop && hg qdelete try</code><br>
+<code>cc-try</code> must be defined in your <code>.hg/hgrc</code> as <code>cc-try = ssh://user@domain@hg.mozilla.org/try-comm-central</code><br>
+You <b>must</b> refresh your patch before or the changes will go into the <code>try</code> patch and will be deleted!
+<b><code>../mach try</code> DESCRIBED BELOW DOES NOT WORK</b>
 These are the differences for the Thunderbird try server:
-* Patches should be pushed to <code><nowiki>ssh://hg.mozilla.org/try-comm-central</nowiki></code>
+* The <code>.hg/hgrc</code> that exists within the <code>comm/</code> folder must contain:
+ [defaults]
+ push-to-try = -s ssh://hg.mozilla.org/try-comm-central
+In order for <code>../mach try <TryChooserSyntaxOptions></code> to work
+* You must run <code>../mach try</code> (note the two dots) from *within* <code>comm/</code>. Running <code>mach try</code> from the <code>mozilla-central</code> (sometimes named <code>source/</code>) directory will not work.
+* After running that command you should see: <code><nowiki>pushing to ssh://hg.mozilla.org/try-comm-central</nowiki></code>
 * Results go to the [https://treeherder.mozilla.org/#/jobs?repo=try-comm-central try-comm-central on treeherder]
-* Finished builds live on http://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/{your_email_changeset}
+* Finished builds can be accessed through treeherder. Click on the green B of the respective platform, then on the bottom click Job Details. In the list of artifact uploads, click the archive for your platform: Linux uses target.tar.bz2, OSX uses target.dmg, Windows uses target.zip
 == Tips and Tricks ==
 * Pushing a try build with try-comm-central will always pick the latest m-c changeset.
+* A good example that should cover most cases is: <code>../mach try -b do -p macosx64,win64,linux64 -u all</code> which will do debug and opt builds and run all tests on all three platforms.  Mac and Linux are quicker to compile (20-30 minutes). Windows builds are longer (60 minutes) so omitting Windows can save some time. The tests take about 20 minutes.
 === Pushing mozilla-central patches ===
-There's two steps to this process.
+For TaskCluster builds, modify the <code>.gecko_rev.yml</code> and point <code>GECKO_HEAD_REPOSITORY</code> to <code>https://hg.mozilla.org/try</code> and also modify <code>GECKO_HEAD_REF</code> to point to the changeset you previously pushed to M-C's try with <code>mach try empty</code>. You can also point to <code>https://hg.mozilla.org/integration/mozilla-inbound</code> or <code>https://hg.mozilla.org/integration/autoland/</code> to pick up latest changes on those repositories.
-# Add --apply-patches to build/client.py-args.
-#* [[ReleaseEngineering/ThunderbirdTryServer/ApplyPatchesMozconfigPatch|Example patch here]].
-#* If you do this as a separate patch in your Mecurial queue, you can reuse it whenever you want. Otherwise this change can go into the patch created in the step 4.
-# Copy your mozilla-central patch to somewhere in your comm-central tree (it can be placed into the root directory) and name it something like: <code>mozilla-&lt;anything&gt;.patch</code> (the <code>mozilla-</code> prefix is essential).
-# <code>hg add</code> your patch.
-# Then <code>hg commit</code> your changes, or use <code>hg qnew</code> for a new item on your patch queue.
-# Push your patches to try-comm-central.
-The client.py code will automatically apply your mozilla-central patch when the code is checked out. Any apply failures will cause the builds to be aborted. The mozilla-central patches are supposedly applied in the alphabetic order of their file names. You can mix comm-central and mozilla-central patches in the same batch being pushed.
-=== Pushing ldap/chatzilla/venkman/DOM Inspector patches ===
-The mozilla build system also supports modifying code from other hg.mozilla.org code repositories for testing on the try server. The approach for this is basically the same as in the [[#Pushing_mozilla-central_patches|Pushing mozilla-central patches]] section, except the patch file name has to be <code>ldap-&lt;anything&gt;.patch</code>, <code>chatzilla-&lt;anything&gt;.patch</code>, <code>venkman-&lt;anything&gt;.patch</code> or <code>inspector-&lt;anything&gt;.patch</code> depending on what patch you want to test.
 == Known issues ==