Creating Toy Builds

{excerpt}
----
h1. Creating Toy Builds


h2. Why?

Perhaps you're making some radical code changes. Perhaps you've embarked on a major redesign of ep-engine, ns_server, and couchstore in one large, brilliant cross-component refactoring.

You want to see if the RPM packaging still works with your changes.

And/or, you wish to provide a "work-in-progress" RPM build to your QE colleagues.

The solution is to kickoff a toy build.

A toy build is an RPM that's built using the same build/compilation libraries, environment and steps that we use for official product builds.

h2. How to make your own toy build

h3. One time setup...

* Checkout and build [https://github.com/couchbase/manifest]
** Follow the manifest's README instructions to make sure you can successfully build couchbase. If your code doesn't build on your own dev box, it won't build on our buildslaves.

* Copy the branch-2.0.xml manifest to toy/toy-YOURNAME.xml. For example...
{code}
cd manifest && cp branch-2.0.xml toy/toy-steve.xml
{code}
** Note, the toy build system looks for manifests that follow the naming pattern of "toy/toy-*.xml".

* Modify your toy/toy-YOURNAME.xml to point to the work-in-progress branches where your changes live...
** These git repositories (a.k.a, "remotes") need to be publically accessible.
** For example, I might have my own personal github account and my own fork/branch of ep-engine, like at git://github.com/steveyen/ep-engine.git, "paxos-experimental" branch.
** In my toy/toy-steve.xml file, I would then add a new <remote name="steve" fetch="git://github.com/steveyen"/> and change the ep-engine project to use that new, steveyen remote and paxos-experimental revision (<project name="ep-engine" path="ep-engine" remote="steve" revision="paxos-experimental"/>).

* Commit your toy/toy-YOURNAME.xml changes and push it to gerrit.
{code}
git push gerrit HEAD:refs/for/master
{code}
** If you don't know gerrit, start here: [Contributing changes]

* Get your toy-YOURNAME.xml gerrit change reviewed, approved and submitted.
** Once it's through gerrit, your toy-YOURNAME.xml should show up here...
** [https://github.com/couchbase/manifest/tree/master/toy]

* Send email to farshid/dustin/steve to reconfigure the buildbot.
** (For farshid/dustin/steve, on the buildbot master, just run: cd Buildbot && make reconfig)

* After reconfiguration, your toy builder should show up here (search for "toy-YOURNAME")...
** [http://builds.hq.northscale.net:8010/builders]
** For example, toy-steve will be listed as "ec2-centos-x64_toy-steve-builder".

h3. Whenever you want another toy build...

* Browse to: [http://builds.hq.northscale.net:8010/builders] and click into your builder
** For example, click "ec2-centos-x64_toy-steve-builder".
* Click the "Force Build" button.
* Go get coffee/tea (15-20 minutes).
** The first time, though, can be much, much longer (1 hour+).
* You can watch your builder's log output pages for progress and for any build errors.
* If your build successfully completed (it's green)...
** You'll see a "git_describe" property that looks like: "2.0.0r-424-ga2cda1e"
** Browse to: [http://builds.hq.northscale.net/latestbuilds/]
** Search for "toy-YOURNAME" and the 64-bit RPM with your particular git hash ("2.0.0r-424-ga2cda1e").
** Download your RPM and go play with it.

h3. If the first build fails

* You will need to provide a fake git_describe value:


!Buildbot_ ec2-centos-x64_toy-aaron-builder - Pentadactyl-1.png|border=1!


h3. Have fun making and breaking your toys...

* [http://www.youtube.com/watch?v=58XyDEPVKSQ]

h3. DISCLAIMER

Toy builds are completely unsupported; they are not QA'ed; do not deploy them to production, etc.