ReleaseEngineering/Mozharness/How to run tests as a developer: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
Line 1: Line 1:
'''NOTE: You can now use your LDAP credentials to authenticate and download the files that are behind Http authentication (e.g. pvtbuilds).'''
== Quick run-down ==
== Quick run-down ==
# Find the command from the log. Copy/paste it.
# Find the command from the log. Copy/paste it.
# Append --cfg developer_config.py
# Append --installer-url/--test-url with the right values
# Append --installer-url/--test-url with the right values
# Append --cfg same_file_path_but_ending_with_dev.py


== Steps ==
== Steps ==
Line 13: Line 15:
Prepend ''python'' before this command.
Prepend ''python'' before this command.


=== Step 3 - A) Append --installer-url and/or --test-url ===
=== Step 3 - Append --cfg developer_config.py ===
This activates the LDAP authentication for private files.
It also removes --read-buildbot-configs from the list of actions.
 
=== Step 4 - Append --installer-url and/or --test-url ===
Append ''--installer-url'' and/or ''--test-url''. You can find the right values on the log:
Append ''--installer-url'' and/or ''--test-url''. You can find the right values on the log:
<pre>
<pre>
Line 22: Line 28:
NOTICE: Talos jobs do not require --test-url.
NOTICE: Talos jobs do not require --test-url.


=== Step 3 - B) Create a buildprops.json ===
=== Example ===
In the previous section we mention to use --installer-url as well as --test-url, this is not necessary if you create a file called buildprops.json since the URLs are already specified inside of it.
We start with this production command:
You can find the information you need by loading a tbpl log and looking for ''"08:14:31    INFO - Using buildbot properties"''.
/tools/buildbot/bin/python scripts/scripts/b2g_emulator_unittest.py --cfg b2g/emulator_automation_config.py --test-suite mochitest --this-chunk 1 --total-chunks 9 --blob-upload-branch mozilla-central --download-symbols ondemand
Don't try to make sense of it. Just copy it without the datestamps (I know, it sucks).
 
=== Step 4 - A) Use a developer config ===
You should be able to simply add --cfg foo_dev.py to the line that is run in production and make it easier for a developer to run the tests (e.g. --cfg android/androidarm.py --cfg android/androidarm'''_dev.py'''). All the files are under the ''configs'' directory.
 
If there's not a developer config available read the section "How to add a developer config".
 
=== Step 4 - B) --no-read-buildbot-config ===
Append --no-read-buildbot-config to the command.
A developer config removes the action "read-buildbot-config" from the list of actions.<br />
Some jobs could work with just this and not need a developer config, however, this is unlikely.
 
== How to add a developer config ==
Developer configs, if appended after a production config, will overwrite the values on the production config.<br />
 
Developer configs have these things in common:
* They have the same name as the production one but instead end with '''"_dev.py"'''
* They overwrite the '''"exes"''' dict with an empty dict
** This allows to use the binaries in your personal $PATH rather than infra-centric paths
* They overwrite the '''"default_actions"''' list
** The main reason is to remove the action called read-buildbot-configs
** WARNING: A production config could add new actions and should be added to the developer config upon review.
* They fix URLs to point to the right public reachable domains
** WARNING: This should be fixed in the future as they can fall out of sync with production


== Private files ==
and we end up with this developer-friendly command:
You can now use your LDAP credentials to authenticate and download the files that are behind Http authentication (e.g. pvtbuilds).
python scripts/scripts/b2g_emulator_unittest.py --cfg b2g/emulator_automation_config.py --test-suite mochitest --this-chunk 1 --total-chunks 9 --blob-upload-branch mozilla-central --download-symbols ondemand \
--cfg developer_config.py \
--installer-url http://pvtbuilds.pvt.build.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-central-emulator/20140910173159/emulator.tar.gz \
--test-url http://pvtbuilds.pvt.build.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-central-emulator/20140910173159/b2g-35.0a1.en-US.android-arm.tests.zip


== Running mozharness on your local machine ==
== Running mozharness on your local machine ==
Follow all the steps mentioned above.
Follow all the steps mentioned above.
== Running mozharness with your local build ==
TODO: I believe --installer-path instead of --installer-url can be used with --cfg dev_config.py, however, we have to verify this and document it properly.


== Running mozharness on a loaner machine ==
== Running mozharness on a loaner machine ==
Line 127: Line 115:
}
}
</pre>
</pre>
== Deprecated ==
=== Step 3 - B) Create a buildprops.json ===
In the previous section we mention to use --installer-url as well as --test-url, this is not necessary if you create a file called buildprops.json since the URLs are already specified inside of it.
You can find the information you need by loading a tbpl log and looking for ''"08:14:31    INFO - Using buildbot properties"''.
Don't try to make sense of it. Just copy it without the datestamps (I know, it sucks).
=== Step 4 - B) --no-read-buildbot-config ===
Append --no-read-buildbot-config to the command.
A developer config removes the action "read-buildbot-config" from the list of actions.<br />
Some jobs could work with just this and not need a developer config, however, this is unlikely.
=== Step 4 - Use a developer config ===
You should be able to simply add --cfg foo_dev.py to the line that is run in production and make it easier for a developer to run the tests (e.g. --cfg android/androidarm.py --cfg android/androidarm'''_dev.py'''). All the files are under the ''configs'' directory.
If there's not a developer config available read the section "How to add a developer config".
== How to create a developer config ==
Developer configs, if appended after a production config, will overwrite the values on the production config.<br />
Developer configs have these things in common:
* They have the same name as the production one but instead end with '''"_dev.py"'''
* They overwrite the '''"exes"''' dict with an empty dict
** This allows to use the binaries in your personal $PATH rather than infra-centric paths
* They overwrite the '''"default_actions"''' list
** The main reason is to remove the action called read-buildbot-configs
** WARNING: A production config could add new actions and should be added to the developer config upon review.
* They fix URLs to point to the right public reachable domains
** WARNING: This should be fixed in the future as they can fall out of sync with production
Confirmed users
3,990

edits

Navigation menu