ReleaseEngineering:ProjectBranchPlanning

From MozillaWiki
Jump to: navigation, search

If your need for an automated branch is of a known length of time, please book a Disposable Project Branch, otherwise if you are looking for a longer term solution and want a new project branch created for your work, please file a bug with this bug template

Copy the questions below, and insert your answers in the bug's comment section so we have the info we need:

  • Project name:
    • Your project name will also be used for the repo name (eg: hg.mozilla.org/projects/jaegermonkey) - please state if you have an existing repo you're looking to use instead of a newly created repo.
    • Note: project names should avoid using confusing/overloaded terms, like "build", "firefox", "release"...
    • Note: Repos for finite-duration project branches will go into http://hg.mozilla.org/projects. Repos for never-ending team/integration branches will go into http://hg.mozilla.org/integration.
  • For builds:
    • All platforms or subset of platforms currently building mozilla-central?
    • Will you use the mozilla-central mozconfigs or will you need custom ones?
    • Nightly builds? Updates for those nightlies ?
  • Need unittests?
    • All platforms or subset of platforms currently testing mozilla-central?
  • Mobile Builds?
    • All platforms or subset of platforms currently building mobile-browser?
  • Need Talos?
    • All talos suites or a subset of suites run on mozilla-central?
  • Name of the contact person for this branch who will:
    • Be doing periodic refreshes from parent
    • Be contact person for misc setup questions
    • Decide when to land back project branch onto parent
    • Decide when to terminate the project branch
  • Timeline:
    • When should this branch go live?
    • Approx expected life span of project branch?

Release Engineering Project Branch Creation Checklist

  • File a ServerOps bug to create repo in hg.m.o if repo does not already exist. Repos should be created under "/projects", "/services" or "/releases" whenever possible.
  • File a Treeherder bug to get the repo added to Treeherder.
  • Create patches in buildbot-configs/mozilla/project_branches adding the project and if needed any custom mozconfig path or custom repo path
    • By default, the project branches use the generic mozconfigs (in buildbot-configs/mozilla2/$platform), if you need custom mozconfigs you should create them across the board as we would prefer at this time to not have a mix of files and symlinks. You can override the 'mozconfig_dir' in the project_branches.py file
    • Example customization is turning on nightly updates, if this comes up you can copy the process from the UX branch see example patch for what is required wrt AUS, once you've enabled nightlies you need to land in cvs, tag and then file a ServerOps bug (example)
    • If you do enable custom nightly channels for a project branch there is a Mac specific issue caused by publishing snippets to a Darwin_x86_64-gcc3 directory, and the clients querying using different build targets so you should use the templates nthomas set up:
# ffxbld@aus2-staging
$ rsync -vdl  /opt/aus2/incoming/2/Firefox/mozilla-central/ /opt/aus2/incoming/2/Firefox/$branch/
  • Do an update to branch and machines tables in graphserver-{staging,production} -- webapp coming in bug 505803 but for now you must generate insert statements by updating data.sql on the 1.0 branch of graphs repo
  • File a ServerOps bug (example bug 633663) to add graphserver entries until this is automated (see bug 627499)
  • Add to self-serve (instructions)
  • Add to regression detector (instructions TODO)
  • Create initial leak test and codesighs logs:
# ffxbld@stage
branch=BRANCHNAME
cd /pub/mozilla.org/firefox/tinderbox-builds/
for p in linux linuxqt linux64 macosx64; do
  mkdir $branch-$p 
  touch $branch-$p/codesize-auto.log
done
for p in linux linux64 macosx64 macosx win32; do
  mkdir $branch-$p-debug
  touch $branch-$p-debug/{malloc.log,sdleak.tree}
done

Once the above items are done and a few pushes have gone through without issue, close the bug - you're done!

Additional Steps For Adding Release Branches

  • File IT bugs:
    • to add Nagios monitoring on checks for file age in firefox/nightly/latest-$branch if required
    • to add mxr indexing (release branches only - see bug 510495 for example)
  • File a Webtools/Socorro bug to add the new branch to vcsMappings:
    • This allows devs to get source links for branch crash reports.
    • Ask for this:
'hg.mozilla.org/REPO' => 'http://hg.mozilla.org/REPLACE_WITH_REPO/annotate/%(revision)s/%(file)s#l%(line)s'
  • Make sure to add mozconfigs for each platform!