Mozharness

From CDOT Wiki
Revision as of 05:57, 18 December 2010 by Mredha (talk | contribs) (Project Plan)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Project Name

Mozharness

Project Description

Imagine that we did not have to touch the Mozilla buildbot factories but instead we maintained a bunch of script for all the different jobs they run?

It would be good if we could create scripts that told a machine how to generate an optimized build, a debug build, unit tests, talos runs, locale repackages. If you look in the tools/scripts repo you can see that we have a simple shell file to do this for the fuzzing automation. The buildbot factory that calls it is called mozharness and it is very simple.

mozharness is a single factory that buildbot can run; within mozharness, a script is selected for a specific job. This moves the job-definition responsibility out from buildbot; by separating the pieces, you avoid excessive complexity in buildbot and also open up the possibility of running mozharness manually (e.g., by a developer, to test something) ment Initial contacts: Armenzg

Project Leader(s)

adrianp: Adrian Pruteanu

mustafaj: Mustafa Redha

Project Contributor(s)

Armenzg

Project Details

  • Objective: Improve efficiency while lowering the entry level knowledge required from new developers to get involved
  • requirements: pylint and coverage
  • ./unit.sh to run unit test coverage
  • scripts directory contain scripts
  • documentation is required
  • scripts written in python
  • separate framework - which buildbot calls
 What are we building?
  • Profile Build
  • Debug Build - For OS (Mac, Linux, Windows, 32/64 etc)
  • Packaged Test - contains test for the build
  • Tests - Mochitests, Reftests, xpcshell, ... 10 in total
    • l10n builds
  The problem that mozharness solves:
  • buildbot uses a "factory" to run a job
  • there are (becoming) too many different "factories" within buildbot


 Outlined in Armen's blog post

Project Plan

Goals for each release:

adrianp - Development Feed - Repository

mustafaj

hgtool port
  • 0.1

- Create the MercurialVCS class that is responsible for basic hg operations (clone, pull, push) each with an individual method

  • 0.2

- Implement all hgtool actions as individual methods in MercurialVCS. At this point MercurialVCS() should be importable (useful) for Mozharness
- Document usage for programmers (inheritance, import, whatever else not pertaining to users shell interaction)

  • 0.3

- lib/source/mercurial.py should be callable via shell with parameters matching each method (ie: ./mercurial.py checkout [src]?)
- The Class should be generalized to ensure portability to other D/VCSs (git, svn, cvs)



0.1 through 0.3 will have a progressive approach.

  • 0.1:
    • - create mercurial repository: Done -->[1]<--

** Download builds and tests get them running on Fedora Linux x64. *** Mochitest and reftest? ** Document the success or problems of these tests (on F13.x64) ** Find out what the meaninfull output will be (These tests run, what are we looking for as a result) ** Scope a specific set of test(s) and options that will be incorporated into moztest.py ** See what logic and scripts can be ported from buildbotcustom to moztest.py


  • 0.2

** Create a basic moztest.py which calls classes from the scripts in the harness to take on options and provide a --help list.

    • Incorporate the automation of:
      • checking the build environment prerequisites
      • create an option to bring system up to date for any missing pre-reqs

***download and unpack builds and tests into a standardized directory structure

      • run a barebones test
    • expand automation to include:
      • all options available for the test chosen

***simplify the options for "easy test and build urls"


  • 0.3

**Document 0.1 and 0.2 in an introduction to moztest.py (mozharness) in an inclusive format geared towards developers using the tool and those that may contribute to it in the future **Continue to expand on moztest.py to address errors

    • TBD midway through 0.3

Project News

  • Friday October 8, 2010:
    • I will try to contact Armen today and find out what his schedule is like, and coordinate with everybody to setup a meeting in CDOT conference room. -Mustafa
  • Tuesday October 12, 2010:
    • Adrian made initial Contact with Armen, meeting set for 3pm Wendesday October 13, 2010 -Mustafa
  • Wednesday October 13, 2010:
    • The mozharness/buildapi/releasebugs group met today with Armen and Ctyler in a conference call. The conference call is logged below -Mustafa

First meeting: mozharness call (2010-10-12 15:00 EDT)

  1. What is mozharness (Armen)
  2. Initial direction
  3. Q&A

Atendees:

  • ctyler, mustafaj, armenzg, adrianp, asingh

Blogs:

... all of which appear on the CDOT Planet