mozilla

Compare Revisions

Mozharness FAQ

Change Revisions

Revision 357159:

Revision 357159 by jgriffin on

Revision 357163:

Revision 357163 by jgriffin on

Title:
Mozharness FAQ
Mozharness FAQ
Slug:
Mozharness_FAQ
Mozharness_FAQ
Content:

Revision 357159
Revision 357163
n642    <h3 id="Interaction_with_other_Comonents">n642    <h3 id="Interaction_with_other_Components">
n645    <h4>n645    <h4 id="Q._How_do_mozharness_and_buildbot_interact.3F.C2.A0_W
 >hat_do_I_need_to_know_about_buildbot_to_write_a_good_mozharness_s
 >cript_or_config.3F.C2.A0_What_do_I_need_to_know_about_build_or_te
 >st_slaves.3F">
n664    <h4>n664    <h4 id="Q._How_do_mozharness_scripts_and_TBPL_interact.3F.C2.
 >A0_How_do_I_get_the_output_of_my_test_run_to_show_up_correctly_in
 >_TBPL.3F">
n681    <h3>n681    <h3 id="Testing">
tt684    <h4>
685      Q. I want to run a mozharness script in a manner with parit
 >y to production.&nbsp; How do I do this?
686    </h4>
687    <p>
688      A. This depends on what you mean by "in a matter with parit
 >y to production".
689    </p>
690    <p>
691      As&nbsp; we add more mozharness scripts and script families
 > to production, we'll&nbsp; have better answers for these questio
 >ns, but as we're adding swaths of&nbsp; new automation, we're hav
 >ing some growing pains.
692    </p>
693    <p>
694      You can test locally, which I encourage.&nbsp; But this isn
 >'t necessarily going to test all production platforms, and especi
 >ally not all production platform configurations.<br>
695      You can have buildduty loan you a machine, which would defi
 >nitely make sure the script could run on production platform conf
 >igurations.&nbsp; If this covered all production platforms, there
 > would be a strong likelihood of things working when rolling out,
 > but it wouldn't necessarily cover the buildbot &lt;-&gt; script 
 >interaction.<br>
696      We also are going to be helping some people set up their ow
 >n staging environments which would help test the buildbot portion
 > of the automation as well.<br>
697      <a href="https://wiki.mozilla.org/ReleaseEngineering/How_To
 >/Setup_Personal_Development_Master" title="https://wiki.mozilla.o
 >rg/ReleaseEngineering/How_To/Setup_Personal_Development_Master">h
 >ttps://wiki.mozilla.org/ReleaseEngineering/How_To/Setup_Personal_
 >Development_Master</a>
698    </p>
699    <p>
700      A project that may help at some point in the future is mozh
 >arness try,&nbsp;&nbsp; which would allow for running scripts in 
 >an environment similar to&nbsp;&nbsp; production:<br>
701      <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=79192
 >4" title="https://bugzilla.mozilla.org/show_bug.cgi?id=791924">ht
 >tps://bugzilla.mozilla.org/show_bug.cgi?id=791924</a>
702    </p>
703    <p>
704      A&nbsp; lot of testing can be done without having these ful
 >l environments set&nbsp; up, but not all of it.&nbsp; It depends 
 >on the scope and level of risk in the change.<br>
705      (A dirty not-so-secret:&nbsp; our best attempts at staging 
 >everything outside production have still missed some testing for 
 >large scale projects.<br>
706      We try to have full staging runs&nbsp; that are "with parit
 >y" by doing the same things, but in ways that only&nbsp; affect s
 >taging reporting, or staging uploads.&nbsp; This requires having 
 >a&nbsp; setup like production but separate.&nbsp; In practice, th
 >is tends to miss&nbsp; small testing elements: for instance, we d
 >on't have a staging tbpl.&nbsp; And&nbsp; since our staging pool 
 >of machines is so much smaller, we don't always&nbsp; get full en
 >d-to-end testing on all platforms and branches on all&nbsp; affec
 >ted builders/testers.
707    </p>
708    <p>
709      For full, 100% parity, the job would likely need to be in p
 >roduction itself, with everything that applies.&nbsp; However, th
 >is would most likely negatively affect other people.&nbsp; Usuall
 >y when testing, you want to avoid affecting production in any way
 >.)
710    </p>
711    <h4>
712      Q. How can I test my mozharness scripts/configs?
713    </h4>
714    <p>
715      A. Absent the above, you can also test locally.
716    </p>
717    <p>
718      unit.sh runs python nosetests on mozharness.&nbsp; Best pra
 >ctice says we should add tests for whatever new code we write.&nb
 >sp; In practice, this hasn't been the case, but this will become 
 >more important as the code base grows and more changes from multi
 >ple developers come in.
719    </p>
720    <p>
721      (It's not always possible to write tests that can be run lo
 >cally for all tests: if they require a platform or environment yo
 >u don't have locally, for example.&nbsp; Someone had a suggestion
 > for how to return pre-cooked output from "fake" external scripts
 > or tools for testing; we need to investigate this.)
722    </p>
723    <p>
724      As you write a script, if you're splitting actions up to be
 > individual chunks as you should, you can test them individually 
 >and make sure they do what you expect before moving on to the nex
 >t one:&nbsp; does this action clobber the directory as expected?&
 >nbsp; Does this one populate the directory tree as expected?&nbsp
 >; Does this one build or package or install or whatever it is, th
 >e way it should?
725    </p>
726    <p>
727      (You can call an action individually by --ACTIONNAME.&nbsp;
 > You can skip an action by --no-ACTIONNAME.&nbsp; You can add an 
 >action to the list of default actions by --add-action ACTIONNAME.
 >&nbsp; You can run two or more actions by --ACTIONNAME1 --ACTIONN
 >AME2.)
728    </p>

Back to History