GSoC idea to setup Gitlab for Fedora Hosted, looking for mentors

Stas Sușcov stas at nerd.ro
Tue Mar 20 15:00:06 UTC 2012


În data de Tue, 20 Mar 2012 16:47:01 +0200, seth vidal
<skvidal at fedoraproject.org> a scris:

> On Tue, 20 Mar 2012 16:39:42 +0200
> Stas Sușcov <stas at nerd.ro> 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?


More information about the infrastructure mailing list