[katello-devel] Own gem repo

[Jason Rist]

On 07/11/2011 10:06 AM, Shannon Hughes wrote:
> justin summed this up well. +1 to keeping our internal gem repo. it was
> a pain hunting down the auto-upgrades pointing to ruby-gems. while some
> of this can be tuned to exact versions, i still feel the internal repo
> that justin setup gives us more control and is more aligned with our rpm
> build process.
> 
> On 07/11/2011 11:53 AM, Justin Sherrill wrote:
>> On 07/11/2011 11:01 AM, Lukas Zapletal wrote:
>>> On 07/11/2011 04:28 PM, Justin Sherrill wrote:
>>>> Generally when you do a bundle install the Gemfile.lock file will be
>>>> updated with all of the newest gems from the repo.
>>>
>>> Is this really true? Because on my box:
>>>
>>> # bundle install -> no change to the .lock file
>>>
>>> # bundle update -> change to the .lock file
>>>
>>> The same in the Bundler documentation.
>>>
>>
>> So I wasn't able to reproduce the 'bundle install', but I can assure
>> you it was an issue a while back.  See internal discussion around
>> march of this year and you'll see a lot of issues with 'bundle
>> install'.  I'm very certain it was an issue.
>>
>> I'm still very against moving back to rubygems.org.  The way we have
>> it now if a developer adds a gem as a requirement for katello they
>> either have to add it to build an rpm for it (for production), or add
>> it to our private gem repo (for development).  If one of these does
>> not happen then the issue becomes very apparent (which it did for you)
>> and hopefullycan be fixed early.
>>
>> If we rely on rubygems.org the issue would not become apparent right
>> away and it may take a few days for QA to hit it (because devs would
>> just be blindly running 'bundle install').
>>
>>
>> Actually I think i remember what the issue is.  User A decides to add
>> a new gem foo-1.1.  He adds  'foo' to Gemfile.  and does a bundle
>> install.  foo-1.1 gets added to Gemfile.lock.  He then builds an rpm
>> appropriately and adds it to the spec file.
>>
>> User B comes in a week or so later and does a bundle install.   But
>> wait! A newer version of foo (1.2) has been added to the rubygems
>> repository.  Since user b does not have foo installed at all, it will
>> pull the latest (1.2) and update the Gemfile.lock.  Gemfile.lock
>> simply dictates what versions rails needs to run, not what will be
>> installed by bundler.  User B, not knowing that he had updated
>> anything does his work and commits Gemfile.lock without really knowing
>> it and breaks everyone else.
>>
>> This may seem like a rare situation, but it was happening almost
>> weekly prior to us moving to our private repo.
>>
>>
>> -Justin
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
> 
> 
+1 to keeping the internal repo for other obvious reasons like if
rubygems goes down.

I've updated the FAQ with this question.

-J

-- 
Jason E. Rist
Senior Software Engineer
Systems Management and Cloud Enablement
Red Hat, Inc.
+1.919.754.4048
Freenode: jrist