From MozillaWiki
Jump to: navigation, search

In the A-team we have recently been focusing on making mozharness easier to use by developers and give more flexibility in its use. Mozharness was originally started with Release Engineering and the A-team has been able to use it to contribute on the side of test jobs.

Some of the changes agreed to be tackled over the next couple of quarters are defined in Mozharness changes. We will migrate that page into here.


This projects' goal

Every work day at Mozilla we run almost a 100,000 jobs a day and most are through mozharness. You can see some of them in here.

Mozharness is mainly developed by Release Engineering (Mozharness). This lines up well with the A-team's mission. This specific page project is making Mozharness easier for developers.

If you want to understand more about mozharness read this page.

Browsing the code

You can use dxr to browse Mozharness's code. You can also use mxr to search repositories that are involved with mozharness.

Filing bugs

If you find any issues running mozharness locally, please let us know by filing a bug. Please attach logs/log_raw.log to the bug it will help us see what you're facing.

Getting help

Join our IRC channel or ask questions in Google group (alternatively you can join the mirroring list).

If you're familiar with mozharness get your name in here so people can reach out to your on IRC:

  • jlund - One of the main contributors
  • catlee - Long time contribuor
  • ahal - Long time contribuor
  • gbrown - - Long time contribuor - Familiar with Android scripts


Using mozharness is very easy. Here's what it takes to run it:

hg clone
cd mozharness

Check the "examples" section for seeing how to run mozharness locally.

NOTE: For some test jobs you will need LDAP credentials. This might limit the ability of community members to try those type of jobs.


You need to have:

  • Mercurial
  • virtualenv

For Windows users you can get all this by installing MozillaBuild.


The following are some examples of test jobs that you can run locally: - Run a Firefox desktop reftest

  • On Linux:
python scripts/ --cfg unittests/ --reftest reftest \
--installer-url \
--test-url \
  • On Windows:
python scripts/ --cfg unittests/ --reftest-suite reftest \
--installer-url \
--test-url \

- Run a Firefox for Android reftest:

python scripts/ --cfg android/ --test-suite reftest-1 \
--installer-url \
--test-url \

- Run a Firefox OS emulator reftest job (NOTE: You will need LDAP credentials):

python scripts/ --cfg b2g/ --test-suite reftest --this-chunk 1 --total-chunks 20 \
--installer-url \
--test-url \

If you want to learn a bit more about different ways we can run jobs running in locally, follow this article: "How to run Mozharness as a developer".

Testing your mozharness changes

You can try your changes locally and then ask for review in the bug.

Unit tests
You can run ./ to ensure that you pass all unit tests.

Testing live Mozharness patches can be tested on the TryServer if you have commit access and a user repo. You can read this and ask for information on how to get the required privileges to do so. Meanwhile, your mentor can help you test the changes for you.

Submitting your patches for review

You can do so by:

  • Create a patch by running "hg diff > my_patch.diff"
  • Click on "Add an attachment" and attach the file
  • Add a description on how this works and known issues
  • Change the feedback dropbox to "?" and enter the email address of the person will check your code
    • That person will receive an email notification and should be getting back to you in the next day or so


Move and extend information used from in-tree mozharness configs

Status: [ON TRACK]

  • [DONE] - Move more mozharness configs to the tree (see here)
  • Extend which information is read from in-tree configs:
    • run_file_names [DONE] bug 1070041
    • all_$category_suites [DONE] bug 1070041
    • specific_tests_zip_dirs [ON TRACK]
    • extra_args [ON TRACK]

Value gained:

  • It will allow us to further experiment with try
  • It give us more control and flexibility
  • It does not require moving mozharness to the tree
  • It helps develop new platforms and new test job support
  • It reduces review burden for releng
  • It reduces the need to change mozharness code
    • Since we can change it in the tree
  • It unblocks other proposals below
  • It allow us to use these configs by mach

Separate production information from job definitions

Separate configuration information into three:

  • [mozharness] generic production relevant config (e.g. in here)
    • This config file can be used by many other jobs, however, specific values should go into their own (e.g. default_actions)
  • [mozharness] job specific values (e.g. in here)
    • This config should have info with regards to which in-tree config to use and which actions to take
  • [in-tree] suite configuration information (e.g. [1])

Get rid of self.tree_config and only use self.config

jlund has more information about this.

Ability to specify a different output parser

STATUS: [DONE] bug 1068153

Value gained:

  • Switch to structured logging parsing

Lock mozharness' repository and version used from the tree

STATUS: [DONE] bug 791924

Value gained:

  • We can test on Try mozharness changes
    • We can not really test properly on Ash (stepping on each others' toes)
  • We remove the need for Ash, Cedar and Cypress

Pin mozharness on all trees

STATUS: {{ok|bug 1110286

Value gained:

  • We can easily backout
  • Reduced risk of breaking the tree across branches
  • Remove the need to merge to the production branch

Move harness command line options into configuration files

All command line options we pass to each harness should live within configuration files. Both mach and mozharness more or less have little test harness configuration in them. This makes it easy to unpack a test package and easily point to a configuration file. This depends on fully moving mozharness configs into the tree (see 3.1)

Value gained:

  • Both mach and mozharness have the same entry points
  • Make it easier to run outside of releng CI
  • There is less diverging paths making maintenance cost lower

Unified return code

Set the results status out of mozharness so that one can be sure that the overall result you get from a mach command is the same as the overall result you would get from a run on infra, given the same output.

Value gained:

  • Both mach and mozharness can output the same result

Move core mozharness functionality to modules

We now have all of the setup being done on the mozharness world (virtualenv, downloads, extracting). We don't have good libraries on the in-tree side to do any of this work. The proposal would be to create mozbase packages that give us the ability to create in-tree scripts that have the power and reliability that mozharness gives.

The proposed functionality to modularize are:

  • mozdownload
  • mozextract
  • mozvirtualenv
  • mozvcs

NOTE: At first, these packages do not need to live inside of mozilla-central since we're not planning on including them inside files.
NOTE2: This project is likely not to happen before any of the others ones happen first. We want to get a pulse of where we stand at that point.

Value gained:

  • Capacity to write scripts that are well suited to run reliably in our CI and meeting expectations
    • We can write them in a more python-fashioned way
    • Easier to write bootstrapping code
      • Mozharness currently does this by using subclassing and Mixin
  • Make mozharness scripts much simpler
    • Download specified in-tree script and run it
    • Less setup in the mozharness side
    • Easier to write tests for mozharness scripts
    • Other teams can write more reliable automation in their own setups
  • Mozharness core functionality becomes part of the tree
    • We get try support
  • Mozharness core functionality is modularized
    • It increases the amount of people that can contribute to the core mozharness functionality


  • We would have to re-write mozharness scripts to use these new mozbase packages
    • We need to make sure we don't have two sets of libraries or we will fall apart

Experimenting - Using python packages freely within mozharness

This needs to be explored (minimum viable product), scoped and bugs filed.

Here's an example of a python package being used within mozharness:

Scope ideas:

  • Find mozharness functionality and move into their own python packages (e.g. bug 1109799)
  • Modify mozharness to include that new python package
  • Test that it works and explain to others how you made it happen
  • Spot which other mozharness functionalisties could be moved into these new python packages
  • Bring the conversation to the mozharness table and we can review it and file bugs

Where can I help?

In order to make mozharness easier for developers we have to make it a delightful and well integrated experience. If you want to help, you can find the list of bugs needed to accomplish listed by difficulty.

Good first easier-mozharness bugs

Link to the list of bugs.
These are good starting bugs:

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Good first bugs

There are also bugs not specific to making mozharness easier, however, they also help release engineering's load. This is a super set of the previous section. Link to the list of bugs.
These are good starting bugs:

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Good next bugs

Link to the list of bugs.
If the good first bugs are depleted or want to try something a bit more complicated (NOTE: these bugs might be a bit more challenging):

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

All easier-mozharness bugs

Link to the list of bugs.
These bugs are likely to only require a bit of mozharness hacking and a lot of other code repositories.

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Completed bugs

Bugs fixed in September

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);