Make sure DB_VERSION gets bumped on DB changes

[GoogleCodeExporter]

See Issue71...

> 2) The DB_VERSION being bumped
> 
> Is there a good way to guarantee this?
> 
> I could probably build into the autobuild functions 
> (http://code.google.com/p/omnidroid/source/browse/#svn/tools/autobuild)
> a check on commit that looks for DB changes and then checks to make sure
> the DB_VERSION and onUpgrade functions were updated as well.  I don't
> imagine the DB classes (names changes/additions/subtraction) will change
> often enough that providing this would be too much of an administrative
> headache.

Original issue reported on code.google.com by case.and...@gmail.com on 14 Jun 2010 at 5:48

[GoogleCodeExporter]

I have a question regarding on how the autobuild script:

1. How is it triggered? Is it a cron job?
2. As I understand it, it is being executed in the Google's server, right? Is 
it possible to execute it remotely for testing purposes? Do you know whether 
Google's server has a Ruby interpreter and what version is it?

Thanks!

Original comment by renc...@gmail.com on 15 Jun 2010 at 3:16

• Changed state: Started

[GoogleCodeExporter]

The README 
(http://code.google.com/p/omnidroid/source/browse/tools/autobuild/README) for 
it could use some more details.

Yes, it's a cronjob that runs every 15 minutes.
No, it doesn't run on Google's server.  I have it running on my local machine.  
So the entry for the crontab is:

*/15 * * * * /path/to/check-build.sh

As an alternative we could have it run on post-commit.  There are 
advantages/disadvantages to both ways.  I implemented the cronjob version 
simply because it was quicker to get up and running.  It also as the advantage 
that with a 15 minute window, it will often eliminate needless builds since 
people will often commit several changes in a short time and it really only 
needs to get built once for that set of commits.  In reality though, it's 
probably better to have it run post-commit trigger and having the autobuild 
scripts updated to be able to handle parallel compilation and testing so that 
each commit is tested.

Original comment by case.and...@gmail.com on 15 Jun 2010 at 3:45

[GoogleCodeExporter]

Also, I made some changes to the scripts that weren't committed.  I'll commit 
those changes so you can get the latest version.

Original comment by case.and...@gmail.com on 15 Jun 2010 at 3:50

[GoogleCodeExporter]

As of now, Google code only offers post-commit hooks through webhooks 
(http://code.google.com/p/support/wiki/PostCommitWebHooks - there are also 
sample codes for using App Engine with Python. App Engine now also supports 
Java and is in Beta stage). However, as discussed in the class, this is not a 
very critical feature and the effort should be placed somewhere else. 
Therefore, I would add some comments in the code as a temporary measure.

Code review for comments:
http://codereview.appspot.com/1676046

Original comment by renc...@gmail.com on 20 Jun 2010 at 1:38

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

If you're not working on this (working on more important issues), I'd be happy 
to take action on these two issues in question:
  * Verify DB changes have been implemented/updated properly
  * Parallelism of build process

Let me know if I can help with these.

Original comment by case.and...@gmail.com on 3 Jul 2010 at 6:35

[GoogleCodeExporter]

Original comment by case.and...@gmail.com on 6 Jul 2010 at 2:21