1037067 - Improve initial setup and docs

Status: RESOLVED FIXED

(Testing Graveyard :: Autophone, defect)

Description

[Mark Côté [:mcote]]

Spun off of bug 1030244, we should make initial setup as painless as possible.  I'm not entirely sure what this entails exactly, since I haven't set Autophone up from scratch and I have a lot of accumulated knowledge; someone setting it up from the first time should be able to come up with specific improvements.

Note that two larger, related items, decoupling from phonedash and generating local reports (bug 1037059) and running against custom builds (bug 1037064) have been spun off and marked as blockers to this bug.

At the same time, the installation docs (INSTALL.md) should be reviewed and updated as needed, and the usage docs (USAGE.md) should be expanded to cover more about customizing the setup and running of tests.

Comment 1

[Mark Côté [:mcote]]

Also, when this is complete, https://wiki.mozilla.org/Mobile/Fennec/Android#Testing should be updated appropriately.

Comment 2

[Geoff Brown [:gbrown] (pto Apr 11-18)]

Some initial impressions...

At first, all seemed very promising. A google search for "autophone" pointed me at https://wiki.mozilla.org/Auto-tools/Projects/AutoPhone, which in turn pointed me to https://github.com/mozilla/autophone, with INSTALL, README, and USAGE documents.

README.md seemed like a good introduction to the project. Minor points to clarify in this document:
 - "Autophone controls one or more mobile devices via Mozilla's SUT agent and adb" -- does it really use both? Actually, maybe this is a detail that should be discussed somewhere else (INSTALL?).
 - "See also phonedash.... At some point, DataZilla will obsolete this." I would prefer a simple description of the present system rather than complicating matters with future plans.

On reading INSTALL.md I tried "pip install -r requirements.txt", which failed on logparser:

$ pip install logparser
Downloading/unpacking logparser
  Could not find any downloads that satisfy the requirement logparser
...

Then I noticed that INSTALL says logparser and mozautolog are only required for unittests and provides links for these. It does not say how to install logparser. The link to mozautolog is wrong.

In the s1s2 section of INSTALL, it says to put web page sources into autophone/files. I probably want to use the pages used for the regular phonedash results...why not include them by default? Most of this section re-creates configs/s1s2_settings.ini -- why not just direct the reader to that file, and put all the extra comments in the file itself?

"unittests also require a local installation of the XRE ... A local build of Firefox can be used". Can I download an XRE too? A link might be handy. Once I have an XRE, what do I do with it? (Several paragraphs later there is "change configs/unittest_default.ini to point to your local environment".)

"If you wish to run a development environment..." What is a development environment? Do I wish to run one?

Do I need to do any of the "unittests" setup steps if I just want to run s1s2?

Are unittests still important? We don't run them regularly, do we?

In general, I would prefer a more task-oriented INSTALL.md: If you want to run s1s2 tests, do x, y, z. To run unittests, ...

USAGE.md points to autophone.py and trigger_runs.py, but my initial experience was disappointing:

$ python autophone.py -h
Traceback (most recent call last):
  File "autophone.py", line 22, in <module>
    from pulsebuildmonitor import start_pulse_monitor
ImportError: No module named pulsebuildmonitor

$ python trigger_runs.py -h
Traceback (most recent call last):
  File "trigger_runs.py", line 7, in <module>
    import pytz
ImportError: No module named pytz

It looks to me like requirements.txt should have additions pulsebuildmonitor, pytz, and beautifulsoup4. (Although some of those may be installed by logparser...?)

USAGE tells me how to get help and how to run unittests. How about s1s2?

Comment 3

[Geoff Brown [:gbrown] (pto Apr 11-18)]

Improving error/warning reporting would help the newbie setup experience too. For instance, if autophone finds no devices configured, it should log a warning.

Comment 4

[Geoff Brown [:gbrown] (pto Apr 11-18)]

(In reply to Geoff Brown [:gbrown] from comment #2)
> It looks to me like requirements.txt should have additions
> pulsebuildmonitor, pytz, and beautifulsoup4. 

Those are already in requirements.txt! I don't understand why I initially had trouble with those. It may have been related to the logparser problem. In any event, I cannot reproduce.

logparser and mozautolog are only referenced by runtestsremote.py, so an argument could be made for removing those modules from requirements.txt and having separate install requirements for unit tests, but that seems complicated.

I don't know how to reliably install logparser from requirements.txt (can I link to the hg repo?), so maybe the best thing to do is to say install logparser manually, then pip install -r requirements.txt.

Comment 5

[Geoff Brown [:gbrown] (pto Apr 11-18)]

(In reply to Geoff Brown [:gbrown] (PTO Sept 15 - Oct 7) from comment #4)
> I don't know how to reliably install logparser from requirements.txt (can I
> link to the hg repo?)

That's easy: -e hg+http://...#egg=blah works fine.

Comment 6

[Geoff Brown [:gbrown] (pto Apr 11-18)]

Attachment: tweak installation, update install docs

This tweaks the requirements.txt to pick up logparser from hg. I tested it on a clean docker image (Ubuntu:12.04) and it worked fine.

It also updates INSTALL.md with an aim to making it shorter and more accurate:
 - no SUTagent setup
 - move s1s2 comments into the .ini example file
 - remove some of the narrative not required for installation.

I will update USAGE.md separately.


Obviously I don't know the history here and I may be missing the point in places; I'm happy to adjust accordingly!

Comment 7

[Geoff Brown [:gbrown] (pto Apr 11-18)]

Attachment: add files/blank.html and files/twitter.html

Instead of making people copy local test files to the files directory, let's include the normal test files -- all set up and ready to go for the common s1s2 case. I pulled these from phonedash.mozilla.org.

Comment 8

[Bob Clary [:bc] (inactive)]

Comment on attachment 8488058 [details] [diff] [review]
add files/blank.html and files/twitter.html

Review of attachment 8488058 [details] [diff] [review]:
-----------------------------------------------------------------

Are we ok with checking these in and 'distributing' them since they are from twitter.com? It is probably fair-use, but I'm not sure.

Also, you are missing the the directory files/twitter_files/ and its contents.

f+ if we can legally do this and if you add the twitter_files directory.

Comment 9

[Bob Clary [:bc] (inactive)]

Comment on attachment 8486624 [details] [diff] [review]
tweak installation, update install docs

Review of attachment 8486624 [details] [diff] [review]:
-----------------------------------------------------------------

::: configs/s1s2_settings.ini.example
@@ +19,5 @@
>  # a web server.
>  local = 
> +# The remote option specifies the web server where the devices
> +# will retrieve the test files for the remote tests. It must
> +# be specified and be reachable from the devices.

Maybe add a comment that for reliable remote measurements, the remote web server should be local to the testing environment. Otherwise there is the possibility of network issues interfering with the measurements.

::: requirements.txt
@@ +1,2 @@
>  -e git://github.com/markrcote/jwt.git#egg=jwt
> +-e hg+http://hg.mozilla.org/automation/logparser#egg=logparser

you will have to update this patch since I've checked in the change from jwt to jot.

Comment 10

[Mark Côté [:mcote]]

Comment on attachment 8488058 [details] [diff] [review]
add files/blank.html and files/twitter.html

Review of attachment 8488058 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah bc has a point.  We probably shouldn't check twitter.html in.  I recommend asking wlach how he handles this; I think maybe he fetches them dynamically, although that would cause some variance.

Comment 11

[Mark Côté [:mcote]]

Comment on attachment 8486624 [details] [diff] [review]
tweak installation, update install docs

Review of attachment 8486624 [details] [diff] [review]:
-----------------------------------------------------------------

::: INSTALL.md
@@ +101,4 @@
>  
>  ### Setting up phonedash ###
>  
> +Set up Phonedash following the instructions at 

Trailing whitespace.

Comment 12

[Geoff Brown [:gbrown] (pto Apr 11-18)]

Attachment: tweak installation, update install docs

Updated for review comments (rebased requirements.txt, added reliable remote measurements comment, whitespace).

r=mcote

Comment 13

[Geoff Brown [:gbrown] (pto Apr 11-18)]

Comment on attachment 8488058 [details] [diff] [review]
add files/blank.html and files/twitter.html

eideticker has the same issue for its real-world web pages like cnn and nytimes and excludes those non-freely-distributable sources from the main eideticker repo (they are kept in the separate ep1 repo). In this light, I don't propose any changes for autophone.

Comment 14

[Bob Clary [:bc] (inactive)]

I wonder if we could just pick a nice page form *.mozilla.org or we can create a custom page that actually uses some of the things we want to measure. We certainly have the right to that. It would be a change in the remote values during the switch over so we would have to coordinate with the developers/consumers of the numbers. We can talk about it when you get back from your hike.

Comment 15

[Geoff Brown [:gbrown] (pto Apr 11-18)]

(In reply to Geoff Brown [:gbrown] (PTO Sept 15 - Oct 7) from comment #12)
> Created attachment 8488731 [details] [diff] [review]
> tweak installation, update install docs

https://github.com/mozilla/autophone/commit/035f6af36d372755a1a7d1e228b4966f52f69b10

I also blogged about my experience with autophone: http://gbrownmozilla.wordpress.com/2014/09/12/running-my-own-autophone/

Comment 16

[Geoff Brown [:gbrown] (pto Apr 11-18)]

Attachment: update USAGE.md

I am not entirely happy with this, but here's an attempt at making this more friendly to newbies. I think these instructions would help get me up and running faster the next time.

Comment 17

[Bob Clary [:bc] (inactive)]

Comment on attachment 8488824 [details] [diff] [review]
update USAGE.md

Review of attachment 8488824 [details] [diff] [review]:
-----------------------------------------------------------------

This is ok as far as it goes but we need to add more. I have several shell scripts that I use multiple times a day to check on the status of Autophone, the job queue, battery state etc. Let's go ahead and land this with the nits fixed. Leave the bug open, and I'll work on it while you are hiking the highlands.

::: USAGE.md
@@ +7,5 @@
> +Be sure to review INSTALL.md before attempting to run Autophone.
> +
> +There are many different usage scenarios, but to get started you probably
> +need to do something like:
> + - configure and run PhoneDash

Phonedash

@@ +10,5 @@
> +need to do something like:
> + - configure and run PhoneDash
> +  -- customize phonedash/server/settings.cfg
> +  -- python server.py <ip address>
> + - configure devices.ini and attach your routed devices

routed -> rooted

@@ +28,2 @@
>  Autophone has a number of command-line options. Run "python autophone.py -h"
> +to see them. 

trailing space

Comment 18

[Geoff Brown [:gbrown] (pto Apr 11-18)]

With nits fixed: https://github.com/mozilla/autophone/commit/02c423456f55b618338f834aeaf09ad5a8a5d3b9

Comment 19

[Geoff Brown [:gbrown] (pto Apr 11-18)]

(In reply to Bob Clary [:bc:] from comment #17)
> This is ok as far as it goes but we need to add more. I have several shell
> scripts that I use multiple times a day to check on the status of Autophone,
> the job queue, battery state etc. Let's go ahead and land this with the nits
> fixed. Leave the bug open, and I'll work on it while you are hiking the
> highlands.

...over to :bc for follow-up.

Comment 20

[Bob Clary [:bc] (inactive)]

Attachment: bug-1037067-v1.patch

I changed the test configuration to not require a config file and to use defaults if one is not found. A warning is issued if there is no config file, but otherwise it will run. I think this will help developers get started without having to worry about test configurations. I've also switched the default to not use pulse and for the logging level to be INFO which I also think is more appropriate for developers. I also added a PRODUCTION.md document detailing the setup used in production since that isn't documented anywhere else.

I'll complete the unit test documentation when we get that back up and running.

This isn't perfect but I think it is an improvement. I've read, written, re-written this so much I'd like to get this in an make additional improvements as we go.

Comment 21

[Geoff Brown [:gbrown] (pto Apr 11-18)]

Comment on attachment 8510399 [details] [diff] [review]
bug-1037067-v1.patch

Review of attachment 8510399 [details] [diff] [review]:
-----------------------------------------------------------------

::: INSTALL.md
@@ +40,4 @@
>  https://git.mozilla.org/?p=automation/ep1.git;a=summary and placed in
>  autophone/files/ep1/twitter.com via
>  
> +    git submodule update --init --remote

Why --remote?

@@ +54,5 @@
> +To be updated as part of
> +[Bug 1079923 - Autophone - update unittests to fix bitrot](https://bugzilla.mozilla.org/show_bug.cgi?id=1079923).
> +
> +<!--
> +<del>

We should do that soon.

::: PRODUCTION.md
@@ +1,3 @@
> +# Autophone Production Configuration
> +
> +* autophone.ini

It's fairly self-evident, but I would feel better if there was a prose preamble here saying something like "These are the configuration files used to run the production instance reporting to phonedash.mozilla.org. Note that several security-sensitive parameters have been replaced with XXXXX."

::: USAGE.md
@@ +2,3 @@
>  
> +## tl;dr
> +

I'm glad there's a summary here. This document seems very complete now, but its length may be intimidating!

@@ +25,5 @@
> +        python autophone.py --devices devices.ini
> +
> +        python autophone.py --devices devices.ini --test-path tests/manifest.ini
> +
> +If you have a more compelling use-case, read the rest of this

"more compelling"? Complicated? Different?

@@ +52,5 @@
> +
> +* try-server build:
> +
> +        python trigger_runs.py --repo=try --build-url=http://ftp.mozilla.org/pub/mozilla.org/mobile/try-builds/[e-mail]-fde6088fe349/try-android/
> +        

whitespace alert!

@@ +55,5 @@
> +        python trigger_runs.py --repo=try --build-url=http://ftp.mozilla.org/pub/mozilla.org/mobile/try-builds/[e-mail]-fde6088fe349/try-android/
> +        
> +* local build:
> +
> +        python trigger_runs.py --repo=mozilla-central --build-url=/mozilla/builds/nightly/mozilla/fennec-opt/dist/

I think these examples are great! Maybe add another (few?) for date/time range and revision range? I struggled to get the syntax right.

@@ +116,5 @@
> +
> +Add an additional section for each device you wish to test.
> +
> +You can use emulators instead of physical devices, but your host
> +operating system must support the "Use Host CPU" option. If you can

s/CPU/GPU/

@@ +318,5 @@
> +then measures Web app start times by detecting `WEBAPP STARTUP
> +COMPLETE` messages in logcat. It is implemented by
> +[tests/webappstartup.py](tests/webappstartup.py).
> +
> +WebappStartupTest is a Performance test and is shared the

Missing a word here?

@@ +337,5 @@
> +Throbber start and Throbber stop messages in the logcat output when
> +running Fennec on a device. It is implemented by
> +[tests/s1s2test.py](tests/s1s2test.py).
> +
> +S1S2Test is a Performance test and is shared the

ditto

@@ +381,5 @@
> +</del>
> +-->
> +
> +#### Configuring Multiple tests simultaneously
> +

Now you are being really thorough!

Comment 22

[Bob Clary [:bc] (inactive)]

Attachment: bug-1037067-v2.patch

(In reply to Geoff Brown [:gbrown] from comment #21)
> Comment on attachment 8510399 [details] [diff] [review]
> bug-1037067-v1.patch
> 
> Review of attachment 8510399 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: INSTALL.md
> @@ +40,4 @@
> >  https://git.mozilla.org/?p=automation/ep1.git;a=summary and placed in
> >  autophone/files/ep1/twitter.com via
> >  
> > +    git submodule update --init --remote
> 
> Why --remote?
> 

It didn't pull down the tip of the remote content without it:
bug 1074454 comment 10

> @@ +54,5 @@
> > +To be updated as part of
> > +[Bug 1079923 - Autophone - update unittests to fix bitrot](https://bugzilla.mozilla.org/show_bug.cgi?id=1079923).
> > +
> > +<!--
> > +<del>
> 
> We should do that soon.
> 

Yeah. I'm going to get to that right away as part of getting the video tests running.

> ::: PRODUCTION.md
> @@ +1,3 @@
> > +# Autophone Production Configuration
> > +
> > +* autophone.ini
> 
> It's fairly self-evident, but I would feel better if there was a prose
> preamble here saying something like "These are the configuration files used
> to run the production instance reporting to phonedash.mozilla.org. Note that
> several security-sensitive parameters have been replaced with XXXXX."
> 

Done.

> ::: USAGE.md
> @@ +2,3 @@
> >  
> > +## tl;dr
> > +
> 
> I'm glad there's a summary here. This document seems very complete now, but
> its length may be intimidating!
> 
> @@ +25,5 @@
> > +        python autophone.py --devices devices.ini
> > +
> > +        python autophone.py --devices devices.ini --test-path tests/manifest.ini
> > +
> > +If you have a more compelling use-case, read the rest of this
> 
> "more compelling"? Complicated? Different?
> 

complicated is it then.

> @@ +52,5 @@
> > +
> > +* try-server build:
> > +
> > +        python trigger_runs.py --repo=try --build-url=http://ftp.mozilla.org/pub/mozilla.org/mobile/try-builds/[e-mail]-fde6088fe349/try-android/
> > +        
> 
> whitespace alert!
> 

Damn, markdown mode is horrible for whitespace and I forgot a last whitespace-cleanup!

> @@ +55,5 @@
> > +        python trigger_runs.py --repo=try --build-url=http://ftp.mozilla.org/pub/mozilla.org/mobile/try-builds/[e-mail]-fde6088fe349/try-android/
> > +        
> > +* local build:
> > +
> > +        python trigger_runs.py --repo=mozilla-central --build-url=/mozilla/builds/nightly/mozilla/fennec-opt/dist/
> 
> I think these examples are great! Maybe add another (few?) for date/time
> range and revision range? I struggled to get the syntax right.
> 

Sure.

> @@ +116,5 @@
> > +
> > +Add an additional section for each device you wish to test.
> > +
> > +You can use emulators instead of physical devices, but your host
> > +operating system must support the "Use Host CPU" option. If you can
> 
> s/CPU/GPU/
> 

done

> @@ +318,5 @@
> > +then measures Web app start times by detecting `WEBAPP STARTUP
> > +COMPLETE` messages in logcat. It is implemented by
> > +[tests/webappstartup.py](tests/webappstartup.py).
> > +
> > +WebappStartupTest is a Performance test and is shared the
> 
> Missing a word here?
> 

WebappStartupTest is a Performance test shares the

> @@ +337,5 @@
> > +Throbber start and Throbber stop messages in the logcat output when
> > +running Fennec on a device. It is implemented by
> > +[tests/s1s2test.py](tests/s1s2test.py).
> > +
> > +S1S2Test is a Performance test and is shared the
> 
> ditto
> 

S1S2Test is a Performance test and shares the

> @@ +381,5 @@
> > +</del>
> > +-->
> > +
> > +#### Configuring Multiple tests simultaneously
> > +
> 
> Now you are being really thorough!

Comment 23

[Mark Côté [:mcote]]

Comment on attachment 8511574 [details] [diff] [review]
bug-1037067-v2.patch

Review of attachment 8511574 [details] [diff] [review]:
-----------------------------------------------------------------

A few issues, but you can fix them on commit (and/or clarify where I'm wrong). r+

::: PRODUCTION.md
@@ +2,5 @@
> +
> +These are the configuration files used to run the production instance
> +of Autophone reporting to phonedash.mozilla.org. Note that several
> +security-sensitive parameters have been replaced with XXXXX.
> +

Wondering if these should be in separate files in a "production" directory or something, rather than making someone copy & paste (& adjust indentation) when setting up a new deployment.

::: USAGE.md
@@ +25,5 @@
> +        python autophone.py --devices devices.ini
> +
> +        python autophone.py --devices devices.ini --test-path tests/manifest.ini
> +
> +If you have a more complicated use-case, read the rest of this

No hyphen in "use case".

@@ +40,5 @@
> +install it on the phones and begin a test run by executing the tests
> +listed in the [test manifest file](#test-manifest-file). If a test run
> +is ongoing, the new job is queued.
> +
> +Once Autophone has completed starting, you can manually trigger test

"completed starting" is odd.  "has started up"?  "has initialized"?  Or something more specific about how we'd know this has happened?

@@ +82,5 @@
> +See
> +[trigger_runs.py command line options](trigger_runspy-command-line-options)
> +for more details on running `trigger_runs.py`.
> +
> +Autophone can be configured to listen to pulse for new fennec

Capitalize "Pulse" and maybe link to Pulse wiki page?

@@ +95,5 @@
> +
> +## Configuring Autophone
> +
> +Autophone has many configuration options which can be used to
> +customize its operation although the default values will be sufficient

Comma after "operation".

@@ +155,5 @@
> +will run. The file is a standard ini file which has a section for each
> +test which can contain a `config` option which points to a test
> +configuration file and per-device options. Tests are implemented as
> +python scripts in the [tests/](tests/) directory. The section name for
> +a test, is the basename of the test's script.

No comma.

@@ +163,5 @@
> +which can be used to provide additional configuration information for
> +the test. If the `config` file does not exist or it otherwise not
> +readable, default values for the settings will be used.
> +
> +The names of the optional devicename options are the device names and

"device names, and"

@@ +202,5 @@
> +          --treeherder-credentials-path=TREEHERDER_CREDENTIALS_PATH
> +          --treeherder-retries=TREEHERDER_RETRIES
> +          --treeherder-retry-wait=TREEHERDER_RETRY_WAIT
> +
> +See the Treeherder related options in

"Treeherder-related"

@@ +292,5 @@
> +      If you set resulturl to None, then each device's results will be
> +      written to comma delimited files named
> +      autophone-results-deviceid.csv. Use None when you do not wish to
> +      post results to a phonedash server and only want local test
> +      results.

Random aside:  thinking about this more, it's kind of funny that you get one *or* the other.  Separate options to enable one or the other or both or none would make more sense.  But this is off topic.  This nice, clear documentation is just making it easier to think about usage. :)

@@ +355,5 @@
> +#### Configuring S1S2Test
> +
> +S1S2Test measures fennec load times for web pages by detecting the
> +Throbber start and Throbber stop messages in the logcat output when
> +running Fennec on a device. It is implemented by

I think "when running Fennec on a device" is redundant at this point, especially since you don't say that in the WebappStartupTest section.

@@ +448,5 @@
> +file to be easily reused. To set up your own Autophone configuration
> +file, copy [`autophone.ini.example`](autophone.ini.example) to
> +`autophone.ini` and edit it to suit your needs.
> +
> +#### autophone.py command line options

This is verbatim from the autophone CLI help, right?  Rather than maintain it in two places, I think you should just reference the -h, --help option here.

@@ +547,5 @@
> +
> +#### trigger_runs.py command line options
> +
> +Once Autophone has started, `trigger_runs.py` can be used to trigger
> +tests for specific builds.

Ditto.

::: autophone.ini.example
@@ +13,4 @@
>  #override_build_dir = None
>  #repos = mozilla-central
>  #buildtypes = opt
> +#lifo=True

Keep spacing consistent.

::: autophone.py
@@ +656,5 @@
>                        dest='emailcfg', default='',
>                        help='config file for email settings; defaults to none')
> +    parser.add_option('--enable-pulse', action='store_true',
> +                      dest="enable_pulse", default=False,
> +                      help='Enable connecting to pulse to look for new builds. '

Capitalize "Pulse".

Comment 24

[Bob Clary [:bc] (inactive)]

Attachment: bug-1037067-v3.patch

(In reply to Mark Côté [:mcote] from comment #23)
> Comment on attachment 8511574 [details] [diff] [review]
> bug-1037067-v2.patch
> 
> Review of attachment 8511574 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> A few issues, but you can fix them on commit (and/or clarify where I'm
> wrong). r+
> 
> ::: PRODUCTION.md
> @@ +2,5 @@
> > +
> > +These are the configuration files used to run the production instance
> > +of Autophone reporting to phonedash.mozilla.org. Note that several
> > +security-sensitive parameters have been replaced with XXXXX.
> > +
> 
> Wondering if these should be in separate files in a "production" directory
> or something, rather than making someone copy & paste (& adjust indentation)
> when setting up a new deployment.
> 

Perhaps I should just make it autophone-production.ini ?

> @@ +40,5 @@
> > +install it on the phones and begin a test run by executing the tests
> > +listed in the [test manifest file](#test-manifest-file). If a test run
> > +is ongoing, the new job is queued.
> > +
> > +Once Autophone has completed starting, you can manually trigger test
> 
> "completed starting" is odd.  "has started up"?  "has initialized"?  Or
> something more specific about how we'd know this has happened?
> 

When Autophone has initialized, it will output a message 'Autophone
started' to the console.  You can then manually trigger test runs on
builds with `trigger_runs.py`. This script can trigger tests given a
build ID, date/time range, revision range, or build url.

> @@ +448,5 @@
> > +file to be easily reused. To set up your own Autophone configuration
> > +file, copy [`autophone.ini.example`](autophone.ini.example) to
> > +`autophone.ini` and edit it to suit your needs.
> > +
> > +#### autophone.py command line options
> 
> This is verbatim from the autophone CLI help, right?  Rather than maintain
> it in two places, I think you should just reference the -h, --help option
> here.
> 
> @@ +547,5 @@
> > +
> > +#### trigger_runs.py command line options
> > +
> > +Once Autophone has started, `trigger_runs.py` can be used to trigger
> > +tests for specific builds.
> 
> Ditto.
> 

I'd like to keep them. I thought it would be nice to have a web page where someone could reference the options easily. It is easy to keep up to date though it does require that we do it when we change the options.

Comment 25

[Bob Clary [:bc] (inactive)]

oops, i forgot to change the autophone-production.ini to remove the md cruft. consider that already done.

Comment 26

[Bob Clary [:bc] (inactive)]

Attachment: bug-1037067-v4.patch

back to PRODUCTION.md with headers instead of lists and <pre></pre> blocks instead of indented code.

Comment 27

[Bob Clary [:bc] (inactive)]

https://github.com/mozilla/autophone/commit/df44529621b578fe7170d480e44ca6ad940a6f2d

I had an emacs fu and introduced an extraneous character in USAGE.md. Fixed in 

https://github.com/mozilla/autophone/commit/6e88ae676c217fbf14bc5707c19a6aaa300aa9d3