[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