[katello-devel] Own gem repo

Shannon Hughes shughes at redhat.com
Mon Jul 11 16:06:28 UTC 2011


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


-- 
Shannon Ray Hughes
shughes at redhat.com
Sr Software Engineer
Systems Management




More information about the katello-devel mailing list