[kforge-dev] auto update and deploy of KForge for testing purposes now running

John Bywater john.bywater at appropriatesoftwarefoundation.org
Sat Apr 22 16:10:20 UTC 2006


Hi Rufus,

Good work! ;-)

Rufus Pollock wrote:

> Over the weekend I created a test installation of KForge that updates 
> nightly to the latest code in trunk, rebuilds, deploys, run tests and 
> restarts the web server. After a bit of tweaking over the last few 
> days (primarily to do with permissions on the host machine) it now 
> seems to be fully functional. The install is available at:
>
>   http://test.kforgeproject.com/


That's really great. It really does upgrade with the latest changes. :-)

>
> Since it is a test install running unstable code and requiring the web 
> server to be stopped and started (so that database can be rebuilt) it 
> is **not** running on the production server but on a 'domestic' machine.
>
> Details of the script are below for anyone else who is interested.
>
> Finally I am happy to note that all tests were passing direct out of 
> svn (though today in core tests i was getting logging errors of the 
> form: kforge [ERROR] There was an error importing plugin package 
> 'kforge.core.plugin.example': No module named example.)


This is a harmless side-effect of some changes I just made. I thought 
there were no more dependencies on the kforge system from with the 
(supposed) independent core code. Alas the plugin system was depended 
on, so I moved it in all to the core. So now (I think) there is one 
dependency of the core system (which leads to the above errors being 
printed): the core system tests currently run against a database that is 
build for the kforge core system. The core mostly doesn't mind about 
that at the moment, basically because the kforge system domain model is 
a super-set of the core domain model. But the core does find the there 
are a number of plugins registered, but it can't find the code for them 
because it's looking in the core' plugin package, and not kforge 
(because it isn't kforge).

But it doesn't matter because the system just prints an error and 
carries on, and there are no tests in the core for these "missing" plugins.

The solution is to complete the separation of the core package from the 
kforge package, and create a separate database for core tests.

Best wishes,

John.

>
> Regards,
>
> Rufus
>
> auto-deploy
> ===========
>
> After a bit of tweaking of kforge-integrationtest-loader I was able to 
> reuse this for the deploy script unchanged except for a few changes in 
> __main__:
>
> {{{
> if __name__ == '__main__':
>     basePath = '/home/kforge/test.kforgeproject.com'
>     instancePath = os.path.join(basePath, 'instance')
>     domainName = 'test.kforgeproject.com'
>     argv = ['<name-of-this-script>', '--base', basePath,
>             '--domain-name', domainName ]
>
>     # we need to stop the web server or we won't be able to delete the db
>     os.system('sudo /etc/init.d/apache2 stop')
>     cmd = 'sudo /bin/chown -R kforge:kforge %s' %  instancePath
>     if os.system(cmd):
>         _print('Command [%s] failed' % cmd, True)
>     status = main(argv)
>     cmd = 'sudo /bin/chown -R www-data:www-data %s' % instancePath
>     if os.system(cmd):
>         _print('Command [%s] failed' % cmd, True)
>     os.system('sudo /etc/init.d/apache2 restart')
>     if status:
>         sys.exit(1)
> }}}
>
> _______________________________________________
> kforge-dev mailing list
> kforge-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/kforge-dev
>
>
>





More information about the kforge-dev mailing list