Difference between revisions of "Mozharness"

From CDOT Wiki
Jump to: navigation, search
(→‎Project Plan)
(→‎Project Plan)
 
(18 intermediate revisions by 2 users not shown)
Line 11: Line 11:
  
 
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)
 
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: [[User:Armenzg|Armenzg]]
 
Initial contacts: [[User:Armenzg|Armenzg]]
  
Line 61: Line 61:
  
 
* there are (becoming) too many different "factories" within buildbot
 
* there are (becoming) too many different "factories" within buildbot
 +
 +
 +
  '''[http://armenzg.blogspot.com/2010/10/releng-contributors-from-seneca.html Outlined in Armen's blog post]'''
  
 
== Project Plan ==
 
== Project Plan ==
Line 66: Line 69:
 
Goals for each release:
 
Goals for each release:
  
−
<table style="border: 1px black solid;">
+
<table style="border: 1px black solid;" cellpadding="3">
 
<tr>
 
<tr>
−
  <th style="width: 50%; border-right: 1px black solid;">adrianp</th><th>mustafaj</th>
+
  <th style="width: 50%; border-right: 1px black solid;">
 +
[http://blog.esmnetworks.com/category/mozharness/ adrianp]
 +
- [http://code.darkminds.org/hg/mozharness/rss-log Development Feed]
 +
- [http://code.darkminds.org/hg/mozharness Repository]
 +
</th>
 +
<th>
 +
[http://mustafaredha.wordpress.com/ mustafaj]
 +
</th>
 
</tr>
 
</tr>
 
<tr>
 
<tr>
 
<td style="vertical-align: top; width: 50%; border-right: 1px black solid;">
 
<td style="vertical-align: top; width: 50%; border-right: 1px black solid;">
 
<!-- adrianp's projects -->
 
<!-- adrianp's projects -->
 +
'''hgtool port'''
 
* 0.1
 
* 0.1
 
- Create the MercurialVCS class that is responsible for basic hg operations (clone, pull, push) each with an individual method
 
- Create the MercurialVCS class that is responsible for basic hg operations (clone, pull, push) each with an individual method
 
* 0.2
 
* 0.2
−
- Implement all hgtool actions as individual methods in MercurialVCS. At this point MercurialVCS() should be importable (useful) for Mozharness
+
- Implement all hgtool actions as individual methods in MercurialVCS. At this point MercurialVCS() should be importable (useful) for Mozharness<br />
 
- Document usage for programmers (inheritance, import, whatever else not pertaining to users shell interaction)
 
- Document usage for programmers (inheritance, import, whatever else not pertaining to users shell interaction)
 
* 0.3
 
* 0.3
−
- lib/source/mercurial.py should be callable via shell with parameters matching each method (ie: ./mercurial.py checkout [src]?)
+
- lib/source/mercurial.py should be callable via shell with parameters matching each method (ie: ./mercurial.py checkout [src]?)<br />
 
- The Class should be generalized to ensure portability to other D/VCSs (git, svn, cvs)
 
- The Class should be generalized to ensure portability to other D/VCSs (git, svn, cvs)
 +
<hr />
 +
<br />
 
</td>
 
</td>
 
<td style="vertical-align: top;">
 
<td style="vertical-align: top;">
 
<!-- mustafaj's projects -->
 
<!-- mustafaj's projects -->
−
* 0.1
+
 
 +
<b>0.1 through 0.3 will have a progressive approach.</b>
 +
 
 +
* 0.1:
 +
 
 +
**<s>- create mercurial repository: Done</s> -->[http://iraq.proximity.on.ca/hg]<--
 +
<s>** Download builds and tests get them running on Fedora Linux x64.</s>
 +
<s>*** Mochitest and reftest?</s>
 +
<s>** Document the success or problems of these tests (on F13.x64)</s>
 +
<s>** Find out what the meaninfull output will be (These tests run, what are we looking for as a result)</s>
 +
<s>** Scope a specific set of test(s) and options that will be incorporated into moztest.py</s>
 +
<s>** See what logic and scripts can be ported from buildbotcustom to moztest.py</s>
 +
 +
 
 
* 0.2
 
* 0.2
 +
<s>** Create a basic moztest.py which calls classes from the scripts in the harness to take on options and provide a --help list.</s>
 +
** Incorporate the automation of:
 +
***checking the build environment prerequisites
 +
***create an option to bring system up to date for any missing pre-reqs
 +
<s>***download and unpack builds and tests into a standardized directory structure</s>
 +
***run a barebones test
 +
** expand automation to include:
 +
***all options available for the test chosen
 +
<s>***simplify the options for "easy test and build urls"</s>
 +
 +
 
* 0.3
 
* 0.3
 +
<s>**Document 0.1 and 0.2 in an introduction to moztest.py (mozharness)</s> in an inclusive format geared towards developers using the tool and those that may contribute to it in the future
 +
<s>**Continue to expand on moztest.py to address errors</s>
 +
**TBD midway through 0.3
 
</td>
 
</td>
 
</tr>
 
</tr>

Latest revision as of 04:57, 18 December 2010

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

Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=Mozharness&oldid=53132"