În data de Tue, 20 Mar 2012 16:47:01 +0200, seth vidal
<skvidal@xxxxxxxxxxxxxxxxx> a scris:
On Tue, 20 Mar 2012 16:39:42 +0200
Stas Sușcov <stas@xxxxxxx> wrote:
Not sure passenger is the problem.
Gitlab uses the awesome Resque[1], so you will need something like
foreman[2] to run the app with it's workers all together (at least
this is the easiest way to do that).
I would go with a different stack like unicorn[4] as the webserver
and use apache (if you really want to keep it, other-way I would
consider nginx) as a reverse proxy.
[1]: https://github.com/gitlabhq/gitlabhq/blob/master/Gemfile#L29
[2]:
http://devcenter.heroku.com/articles/procfile#developing_locally_with_foreman
[3]:
https://github.com/gitlabhq/gitlabhq/blob/master/Procfile.production
[4]: https://github.com/blog/517-unicorn
1. For authentication/authorization I think apache is going to be a
requirement
2. Packaging is critical - we will not be installing a thousand gems
directly. They will need to be packaged.
one thing I've not understood about gitlabhq as a development project
is where is the development portion of it? We're not talking about
writing much code, I think. It is mostly about setting up and
integrating gitlabhq into the overall fedorahosted infrastructure.
Looks like packaging the Gitlab dependencies might be an issue, mostly
because of their number and because that number might change in time.
Should we consider setting up an on-demand buildbot for gems. This way
users will be able to submit requests for automatic building of gems?
_______________________________________________
infrastructure mailing list
infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
