How To Break The Build

Owned by Former user (Deleted)
Last updated: Oct 29, 2011 by Michael VorburgerVersion comment

Go Ahead, Break My Day

In Mifos source control head/master (the "master" branch of the "head" repository) is the "bleeding edge" of development. Ideally, this branch will always be stable But accidents happen, so here's what to do when you break the build.

  • be stoked, don't panic!
  • as soon as you notice you've broken the build, please try to fix the build immediately
  • if you can't fix it within a couple of hours, revert head/master to the last stable revision
  • if you aren't able to fix it, can't/didn't revert, and need to log off at the end of the day, let other developers know on IRC and send an email to the mifos-developer mailing list detailing
    • why the build (might) be broken
    • what (might) need to happen to fix it
  • never check in code onto a broken build (unless you are working to fix the broken build)
  • if you notice that someone else may have broken the build
    • reach out to them, ask them what's up on IRC and the mailing list
    • offer to help fix the build, and let folks know you're doing so on IRC and/or the developer mailing list
    • work against a known good revision
  • don't "commit and split", try to integrate your work early in the day
  • merge your code into a branch starting with the name "hudsonBuild", like "hudsonBuildTryNewDatabaseSettings", and push the branch to sf.net. Hudson will automatically build any branch in head named thusly. When done, delete the branch.

If you notice the build is broken

  • Never check in code onto a broken build! (Unless you are working to fix the broken build.)

This is to make things easier for the person who broke the build - if they have to revert, having other checkins will make things harder to fix.

This will cause problems for you, if you want to check in - this is understood. If you really need to check in, find the person fixing the build and help them (pair program with them, etc.). Ideally, the person fixing the build would already have all the help they need. Fixing the build is high priority.

  • First priority is to fix the build.

If you are a core committer, and the build is broken, drop what you are doing and find the person that is fixing the build and help them. If you don't find anyone fixing the build - either recruit people to do so, or do it yourself. The best and most direct way to do this is to just revert changes until the build passes.

Why is this important? It's because no forward progress can be made without a passing build. Without a working build, we do not have working software, and no-one can verify their software works.

Experiment on hudsonBuild branches

Hudson has a job which automatically builds any branches starting with hudsonBuild. Use this to test experimental or WIP (work-in-progress) code.

Here's an example. Assume the current working directory is the top-level of a clone of our "head" repository, currently checked out to a branch called "master" which tracks "origin/master":

# Create new WIP branch off master:
git checkout -b hudsonBuild-someWIP --track origin/master

# Make experimental changes, commit them.

# Push upstream:
git push origin hudsonBuild-someWIP

# Hudson sees the branch appear and automatically builds the code.

# If others have meanwhile done other work on master, you'll first have to:
git checkout hudsonBuild-someWIP
git pull --rebase

# If you like the changes and want them on master, do EITHER this:
git checkout master
git merge --ff-only hudsonBuild-someWIP

# OR, alternatively, get your WIP into master as follows (this usually works better, with less stupid merge conflicts) :
rm *patch
git checkout hudsonBuild-someWIP
git format-patch origin/master
git checkout master
git am --ignore-space-change --3way --ignore-date *.patch

# Now push your work to master!
git push origin master

# Whether you keep the changes or not, prune the branch from the remote server (note the colon):
git push origin :hudsonBuild-someWIP

# Switch back to master and delete the WIP branch:
git checkout master
git branch -d hudsonBuild-someWIP

# Or if for whatever reason you like to keep WIP branch around locally for a moment, then instead:
git checkout master
git branch -m hudsonBuild-someWIP _DONE_hudsonBuild-someWIP

See Also