Build Czar Duties

Th main duties of the Build Czar are summarized as follows

  • Continuously monitor the builds using the Scoreboard as one of the primary source of information.
  • Notify developers who broke compilation to fix the errors as soon as possible, ideally by the next day. A red color in the "Compile" column is not at all acceptable - the Build Czar needs to ensure that these problems are identified and fixed in a timely manner. If possible, the Build Czar should let developers know what the source of problems might be. It is quite possible that developers who checked in the code or users who provided the patch may not have resources to investigate the issues, so the Builds Czar's help is essential to keep things moving ahead.
  • Keep an eye on the tests that are run in every build. Anything abnormal needs to be notified to the right developer. The Build Czar should try helping the developer by providing stack traces (in case of crashes) or other details like printouts with debugging level turned on.
  • Some tests fail in the daily builds for many reasons like known bugs, transient timeouts etc. Make sure that no new test failures show up. This guy knows most of the information. Ask him to help you out with known problems.
  • Keep an eye on the footprint and performance stats. Any abnormal changes should be brought to the attention of the developer resposible for it or to the devo group.
  • Keep the builds ticking. Any red on the "Last Finished" column in the Scoreboard should be fixed. The link to the "Build Name" indicates the machine where the build is being run.
  • The builds don't cover all the possible configurations. If you get a bug report about a compile error in a particular configuration, try setting up a build to make sure that it doesn't show up again if it has been fixed.
  • Keep an eye on the bugzilla entries that are registered by users and developers. Decide on the bugs that need to be fixed for the beta and pain developers for an ETA.

    The document here talks about the powers of a build Czar.

    The Build Czar is empowered to set up more builds on his own for his convenience. This page has a step by step instructions on how to do that.

    The build czar can get the build configuration by looking at the config portion of the scoreboard.

    Pro-active involvement by the build czar is necessary. Being a pro-active build czar requires monitoring the subversion archive carefully and responding quickly to suspected changes to keep the repo stays stable.


    Recipe for Cutting a Beta/Minor Kit

    The build czar is also in charge for the release of the beta. Cutting a beta is as simple as cutting butter if things go well. Here is the procedure followed while cutting a beta:

    1. The whole process takes somewhere between 8-9 hours, about 2 hours for making the release itself and the remaining time for generating the doxygen documentation.
    2. I suggest you take advantage of GNU Screen so that even if your SSH session is interrupted, the cutting process can continue.
      • type screen to start screen.
      • execute commands as normal. Note that Ctrl-A is special in screen, so you need to type Ctrl-A-A to send a Ctrl-A to the shell
      • should your session be interrupted, reconnect and type screen -x
      • when finished, just type exit twice
    3. Prior to starting this, gather aggregate release notes from all developers. This is usually in the form of an email plea asking for a writeup of significant changes since the last beta. Add these notes to the NEWS files before cutting the release so that all notes are part of the release.
    4. Checkout a new workspace on anduril.dre.vanderbilt.edu
    5. Set $DOC_ROOT to point to the new workspace you checked out.
    6. Set an environment variable SIGNATURE indicating your full name. This is used to fill the ChangeLog entry.
    7. Set an environment variable MAILID indicating your mail id. This is used to fill the mail id portion of the ChangeLog entry.
    8. Change directories to to $DOC_ROOT
    9. Tag the release by executing ACE/bin/make_release.py --beta --update --tag This will only take a couple minutes to complete.
    10. Create the kits by executing ACE/bin/make_release.py --kit This will take about two hours to complete.
      • These commands only tags and creates the kits for the software itself, not documentation.
      • The kits end up in /export/anduriltmp/bczar/packages

      To summarize, the following is a transcript of the steps up to this point executing successfully:

      sm@beatrice ~
      $ ssh bczar@anduril.dre.vanderbilt.edu
      No default printer
      -bash-3.00$ cd /export/anduriltmp/bczar
      -bash-3.00$ export DOC_ROOT=$PWD/DOC_ROOT
      -bash-3.00$ export SIGNATURE="Simon McQueen"
      -bash-3.00$ export MAILID=sm@prismtech.com
      -bash-3.00$ svn co https://svn.dre.vanderbilt.edu/DOC/Middleware/trunk DOC_ROOT
      -bash-3.00$ svn co https://svn.dre.vanderbilt.edu/DOC/MPC/trunk DOC_ROOT/ACE/MPC
      -bash-3.00$ cd DOC_ROOT/
      -bash-3.00$ ACE/bin/make_release.py --beta --update --tag
      -bash-3.00$ ACE/bin/make_release.py --kit

      Feel free to cut and paste with suitable edits.

    11. In the EXTREMELY unlikely event that something goes wrong during the tagging of the repo (ie, make_release -v beta -u), the following files must be returned to the state they were in before the release process started and then checked back into SVN:
      ACE/ChangeLog
      ACE/PROBLEM-REPORT-FORM
      ACE/VERSION
      ACE/TAO/ChangeLog
      ACE/TAO/PROBLEM-REPORT-FORM
      TAO/VERSION
      CIAO/ChangeLog
      CIAO/PROBLEM-REPORT-FORM
      CIAO/VERSION
      CIAO/ciao/Version.h
      TAO/tao/Version.h
      ace/Version.h

      In most cases, a svn revert -R * from DOC_ROOT will suffice.
      The tag will also need to be removed (both in Middleware and MPC): ACE+TAO+CIAO-X_Y_Z (where X and Y are the minor and beta release numbers of the release that is to be restarted).

      E.g.:
      svn rm https://svn.dre.vanderbilt.edu/DOC/Middleware/tags/ACE+TAO+CIAO-X_Y_Z
      svn rm https://svn.dre.vanderbilt.edu/DOC/MPC/tags/ACE+TAO+CIAO-X_Y_Z
      Note that this only needs to be done if the tagging fails. If kit creation fails, simply restart that process.

    12. The packages end up by default under $DOC_ROOT/packages-PID, you can copy them to the webserver using the following commands. At the moment you execute these commands all users can download these packages.
    13. cp $DOC_ROOT/packages-PID/ACE* /export/www/download.dre/ACE+TAO-distribution
    14. After the repository is tagged you can start generating the doxygen documentation.
    15. Login to naboo.dre.vanderbilt.edu as bczar: ssh bczar@naboo.dre.vanderbilt.edu
    16. go to /web/users/isisbuilds/tmp/ACE_wrappers and remove the contents of this directory
    17. Update the workspace with the right version tag
    18. svn co svn://svn.dre.vanderbilt.edu/DOC/Middleware/tags/ACE+TAO+CIAO-X_Y_Z/ACE ACE_wrappers
      svn co svn://svn.dre.vanderbilt.edu/DOC/Middleware/tags/ACE+TAO+CIAO-X_Y_Z/TAO ACE_wrappers/TAO
      svn co svn://svn.dre.vanderbilt.edu/DOC/Middleware/tags/ACE+TAO+CIAO-X_Y_Z/CIAO ACE_wrappers/TAO/CIAO
    19. Set the needed environment variables using
    20. export ACE_ROOT=/web/users/isisbuilds/tmp/ACE_wrappers/ACE_wrappers
    21. Run doxygen --version within the shell.
    22. Open up $ACE_ROOT/bin/generate_rel_manpages in your favorite editor.
    23. Search for the string 'doxy_version'.
    24. Check the version specified here. If it is the same as the one you got using doxygen --version then you don't have to worry.
    25. If it is different change the value of the doxy_version to the one installed on naboo.dre.vanderbilt.edu.
    26. Now you are ready to create documentation
    27. Do a cd $ACE_ROOT and then run make -f Release manpages to create the doxygen documentation.
    28. While doxygen churns, format a release announcement, including the release notes gathered from developers. You can use these as an example.
      • Let Doug Schmidt review these before you do anything with them.
    29. Check the file, generate_rel_manpages into the repository if you have made some changes to it.
    30. Make sure the new version is available in Bugzilla.
    31. Now update the documentation at www.dre.vanderbilt.edu/Doxygen.
    32. Update in the autobuild archive the file configs/scoreboard/releases.xml with the made release. This is used by the integrated scoreboard on http://remedy.nl
    33. You should also the packages to the previous versions directory with the appropriate decorators. Do this after the doxygen documentation packages are ready so that these are also archived.
      • cd /export/www/download.dre/ACE+TAO-distribution
      • Modify /export/anduriltmp/bczar/copy_script to use the correct version X.Y.Z and run it.
    34. Mail the approved release announcement out to, at minimum the following: ciao-users@cs.wustl.edu, tao-users@cs.wustl.edu, tao-announce@cs.wustl.edu, ace-users@cs.wustl.edu, ace-announce@cs.wustl.edu. Do this as yourself (not as bugzilla). N.B. You will not be able to post to the users' lists unless you are subscribed to them. Odds are you will not be able to post to the announce lists at all. Ask someone else (like Doug) to do this step.
    35. When all cidlc builds are ready with the new version, login to naboo.dre.vanderbilt.edu as bczar and run ./cut_cidlc.sh version-number fe ./cut_cidlc.sh 0.6.0. If this script is not in its place, then the original is in the bin directory of the distribution.
    36. Update docs/Download.html to show the new release. Make sure you refer to the previous_versions directory, that way we can exactly track how many people download a specific version.
    37. Update etc/index.hml to show the new doxygen package you installed


    Tips to being a Build Czar

    1. Trust no one.
    2. Be careful with this guy, he is notorious in breaking builds (and fixing them as well...Rumour has it that it's actually a super-scalar, super-pipelined processor capable of out-of-order execution, in human incarnation).
    3. Don't forgive people who break ACE :-)
    4. If a build hasn't run in a long time (symptoms are a "red" in the Last Run column of the build scoreboard), delete the .disable file in /path/to/build/directory/BUILD_NAME/ by hand.
    5. Think of the group who wrote the scoreboard update script, every time you catch an otherwise not so obvious error with the help of the scoreboard. Tell DEVO group about it.
    6. Add $CVSROOT/CVSROOT/etc/FROZEN to freeze the repo
    7. Add names of people who need to be given permission and make sure that you add your name so that you can see what is being checked in.
    8. Leave a line at the end of the FROZEN file
    9. Compile once on Win32, Linux and Solaris before cutting a beta.
    10. Trust the release script when making a release. Don't make tar balls by hand. Make sure that the public ftp directories (/project/beguine/ftp/pub/ACE+TAO-distribution and /project/beguine/ftp/pub/ACE+TAO-distribution/diffs) have the right permissions, so that the release script can copy the tar balls.
    11. When making a release, make sure that all the auto_compiles on that machine (deuce.doc.wustl.edu) are stopped. Also make sure that there is enough space in /tmp on that machine.
    12. When all hell breaks loose, don't wait for the nightly builds to monitor improvement. Instead manually start the builds.
    13. Maintain private up-to-date workspaces for problem platforms (read as Solaris).
    14. Don't hesitate to ask for help.
    15. When you get an account to access the cvs repo, make sure you are added to the correct groups, for example, gid=100(users),5000(doc),5002(acetaodev),5003(cvs). Otherwise you will have problem to checkout various modules.
    16. Install your public key to the different machines you have frequent access to avoid typing password.
    17. Update this page if you have any more tips for future build czars :-). This page is in svn under ACE_wrappres/docs/bczar/bczar.html

    The Realm of the Build Czar


    Build Czar Arthur

    Many years have passes since the days of the legendary Build Czar Arthur. His duties were given to him by the mystical Lady of the Lake, who outlined the first responsibilities of the Build Czar.


    Then bespake the Lady of the Lake,
    And these were the words said shee:
    "I knoweth of thy deeds, thou noble Arthur,
    but thy task hath not finished for thee"

    "Thou shalt feitch thy trusty steed,
    And cleanse thy builds againe;
    Then shallt thy ryde hath finnished,
    When new kits released thee cann."

    Then bespake him noble Arthur
    And these were the words said he:
    "With what weapons shallt I use,
    To asure these from the devil free?"

    Then appeered before noble Arthur,
    Uppon the ground a sacred scroll
    Conjurred by the Lady of the Lake
    Borne of the earth in a roll.

    She saies, "Clasp this to thine selfe
    For thee shallt find need for it.
    It shall keep others in the cold,
    Only to be ressurected when thee sees fit."

    "Others shall join thy person,
    To ryde with thee in thy quest;
    Thee shallt be thankful of theire help,
    And to alsoe hold them steadfast."

    "But if theire talke too lodly rise,
    And causeth much damage to thine cuntry,
    He must come forth, and make proclamation,
    For the next one he shall be."

    So hath Arthur to the Lady spoke:
    "For I sweare, and save my othe,
    While enimes and evils I seeke,
    I shall fight against them bothe.