Hi.
I'm experiencing a bit of a nuisance - we don't stage our Gemfile.lock in
the git repo. This causes some annoying issues regarding gem versions. My
latest issue was that the gem we use for LDAP changed the exception class
it throws on an invalid lookup key (or something similar), in turn, this
made some tests fail.
This will keep happening unless we have Gemfile.lock for our project.
Pros:
everyone uses the same gem versions, code works in expected ways
everyone remains sane.
Tom doesn't break his mac out of frustration, and won't need to
explain broken mac to his manager
Cons
a bit more work, as staging Gemfile.lock means some merge conflicts
once in a while.
will need to have a few Gemfile.lock files, one for each minor ruby
version (1.9, 2.0, 2.1 and 2.2), as some gems differ between versions
I know katello used to do this when there was a lot of churn in (some?) gems. It certainly helped things, as I recall. There have been some problems recently that have blocked tests and development upstream related to gem versions too, that seemed to take too much discussion and length in addressing.
Tom, I think I know some of the pros to this but can you share some of the cons?
Thanks for bringing this up!
···
----- Original Message -----
> Hi.
> I'm experiencing a bit of a nuisance - we don't stage our Gemfile.lock in
> the git repo. This causes some annoying issues regarding gem versions. My
> latest issue was that the gem we use for LDAP changed the exception class
> it throws on an invalid lookup key (or something similar), in turn, this
> made some tests fail.
> This will keep happening unless we have Gemfile.lock for our project.
>
> Pros:
>
> 1. everyone uses the same gem versions, code works in expected ways
> 2. everyone remains sane.
> 3. Tom doesn't break his mac out of frustration, and won't need to
> explain broken mac to his manager
>
> Cons
>
> 1. a bit more work, as staging Gemfile.lock means some merge conflicts
> once in a while.
> 2. will need to have a few Gemfile.lock files, one for each minor ruby
> version (1.9, 2.0, 2.1 and 2.2), as some gems differ between versions
>
>
> What do you guys think?
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
It would also include the bundler groups that are enabled or disabled by
the user - we design these to be optional, so a Gemfile.lock means you
need them all.
It also includes plugins, which are gems. If you installed a plugin on
your Foreman instance, it would change Gemfile.lock yet again.
I can't see how it could work.
···
On 25/01/15 12:49, Tom Caspy wrote:
> Cons
>
> 1. a bit more work, as staging Gemfile.lock means some merge conflicts
> once in a while.
> 2. will need to have a few Gemfile.lock files, one for each minor ruby
> version (1.9, 2.0, 2.1 and 2.2), as some gems differ between versions
I like Gemfile.lock being ignored. I think the major benefit is that we find
potential issues caused by new versions early. Also I think it's better to
solve smaller issues continuously rather then one big issue during complete
update. When you update too many gems at once it may be hard to see, what's
causing which issue.
···
On Sunday 25 of January 2015 04:49:14 Tom Caspy wrote:
> Hi.
> I'm experiencing a bit of a nuisance - we don't stage our Gemfile.lock in
> the git repo. This causes some annoying issues regarding gem versions. My
> latest issue was that the gem we use for LDAP changed the exception class
> it throws on an invalid lookup key (or something similar), in turn, this
> made some tests fail.
> This will keep happening unless we have Gemfile.lock for our project.
>
> Pros:
>
> 1. everyone uses the same gem versions, code works in expected ways
> 2. everyone remains sane.
> 3. Tom doesn't break his mac out of frustration, and won't need to
> explain broken mac to his manager
>
> Cons
>
> 1. a bit more work, as staging Gemfile.lock means some merge conflicts
> once in a while.
> 2. will need to have a few Gemfile.lock files, one for each minor ruby
> version (1.9, 2.0, 2.1 and 2.2), as some gems differ between versions
>
>
> What do you guys think?
> > Hi.
> > I'm experiencing a bit of a nuisance - we don't stage our Gemfile.lock in
> > the git repo. This causes some annoying issues regarding gem versions. My
> > latest issue was that the gem we use for LDAP changed the exception class
> > it throws on an invalid lookup key (or something similar), in turn, this
> > made some tests fail.
> > This will keep happening unless we have Gemfile.lock for our project.
Thanks for reporting the issue and keeping our stack up-to-date.
> >
> > Pros:
> >
> > 1. everyone uses the same gem versions, code works in expected ways
> > 2. everyone remains sane.
> > 3. Tom doesn't break his mac out of frustration, and won't need to
> > explain broken mac to his manager
<trolling>Not sure if broken mac is pros or cons </trolling>
> >
> > Cons
> >
> > 1. a bit more work, as staging Gemfile.lock means some merge conflicts
> > once in a while.
> > 2. will need to have a few Gemfile.lock files, one for each minor ruby
> > version (1.9, 2.0, 2.1 and 2.2), as some gems differ between versions
> >
> >
> > What do you guys think?
>
> I like Gemfile.lock being ignored. I think the major benefit is that we find
> potential issues caused by new versions early. Also I think it's better to
> solve smaller issues continuously rather then one big issue during complete
> update. When you update too many gems at once it may be hard to see, what's
> causing which issue.
+1 for not keeping the Gemfile.lock: I prefer debugging and fixing the issues that appear every now and then
in developers setup, and learning about the potential incompatibilities
than doing all of that at once (or worse not doing so as well and ending up
with obsolete versions of the packages). If there is a known constraint on
some version, IMO it should be explicitly stated in the Gemfile (ideally
with a link to an issue describing the problem). It should be in our intention
to keep our stack up-to-date.
Another thing is Gemfile.lock plays no role in production environment,
where the pacakge repository is the authoritative source of truth
for which versions will be used. For me another reason to keep
the version constraints more explicit, the doing so implicitly with Gemfile.lock.
– Ivan
···
----- Original Message -----
> On Sunday 25 of January 2015 04:49:14 Tom Caspy wrote:
I would however suggest one thing that might be helpful and includes the Gemfile.lock:
Then running tests in the Jenkins, we could store the Gemfile.lock that was used there
as a build artifact: so that, when experiencing some issues locally, one could grab the Gemfile.lock
from some passing tests and test if that might or might not be an issue with a gem update.
From running a diff on the Gemfile.lock, one could that easily notice the version changes
that might potentially identify the root of the problem
– Ivan
···
----- Original Message -----
>
>
> ----- Original Message -----
> > On Sunday 25 of January 2015 04:49:14 Tom Caspy wrote:
> > > Hi.
> > > I'm experiencing a bit of a nuisance - we don't stage our Gemfile.lock in
> > > the git repo. This causes some annoying issues regarding gem versions. My
> > > latest issue was that the gem we use for LDAP changed the exception class
> > > it throws on an invalid lookup key (or something similar), in turn, this
> > > made some tests fail.
> > > This will keep happening unless we have Gemfile.lock for our project.
>
> Thanks for reporting the issue and keeping our stack up-to-date.
>
> > >
> > > Pros:
> > >
> > > 1. everyone uses the same gem versions, code works in expected ways
> > > 2. everyone remains sane.
> > > 3. Tom doesn't break his mac out of frustration, and won't need to
> > > explain broken mac to his manager
>
> Not sure if broken mac is pros or cons :)
>
> > >
> > > Cons
> > >
> > > 1. a bit more work, as staging Gemfile.lock means some merge conflicts
> > > once in a while.
> > > 2. will need to have a few Gemfile.lock files, one for each minor ruby
> > > version (1.9, 2.0, 2.1 and 2.2), as some gems differ between versions
> > >
> > >
> > > What do you guys think?
> >
> > I like Gemfile.lock being ignored. I think the major benefit is that we
> > find
> > potential issues caused by new versions early. Also I think it's better to
> > solve smaller issues continuously rather then one big issue during complete
> > update. When you update too many gems at once it may be hard to see, what's
> > causing which issue.
>
> +1 for not keeping the Gemfile.lock: I prefer debugging and fixing the issues
> that appear every now and then
> in developers setup, and learning about the potential incompatibilities
> than doing all of that at once (or worse not doing so as well and ending up
> with obsolete versions of the packages). If there is a known constraint on
> some version, IMO it should be explicitly stated in the Gemfile (ideally
> with a link to an issue describing the problem). It should be in our
> intention
> to keep our stack up-to-date.
>
> Another thing is Gemfile.lock plays no role in production environment,
> where the pacakge repository is the authoritative source of truth
> for which versions will be used. For me another reason to keep
> the version constraints more explicit, the doing so implicitly with
> Gemfile.lock.
>
> -- Ivan
>
> >
> > --
> > Marek
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to foreman-dev+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
I've worked on Rails projects for most of my career and have always checked Gemfile.lock in source control. And rarely have I updated more than one gem at a time. This seems more like a workflow issue than an issue with checking Gemfile.lock into source control. Moreover, there are tools that can continuously tell you what needs to be updated in your Gemfile (www.gemnasium.com) as opposed to having a new gem version randomly breaking the test build.
Overall though, I tend to agree that checking in a Gemfile.lock into source control for Foreman would be infeasible. People have localized gems, configured gem groups, gem dependencies from plugins, different supported platforms, etc. so +1 to not checking in Gemfile.lock.
David
···
----- Original Message -----
> From: "Marek Hulan"
> To: foreman-dev@googlegroups.com
> Sent: Monday, January 26, 2015 3:47:59 AM
> Subject: Re: [foreman-dev] Gemfile.lock - discussion - should it be staged?
>
> On Sunday 25 of January 2015 04:49:14 Tom Caspy wrote:
> > Hi.
> > I'm experiencing a bit of a nuisance - we don't stage our Gemfile.lock in
> > the git repo. This causes some annoying issues regarding gem versions. My
> > latest issue was that the gem we use for LDAP changed the exception class
> > it throws on an invalid lookup key (or something similar), in turn, this
> > made some tests fail.
> > This will keep happening unless we have Gemfile.lock for our project.
> >
> > Pros:
> >
> > 1. everyone uses the same gem versions, code works in expected ways
> > 2. everyone remains sane.
> > 3. Tom doesn't break his mac out of frustration, and won't need to
> > explain broken mac to his manager
> >
> > Cons
> >
> > 1. a bit more work, as staging Gemfile.lock means some merge conflicts
> > once in a while.
> > 2. will need to have a few Gemfile.lock files, one for each minor ruby
> > version (1.9, 2.0, 2.1 and 2.2), as some gems differ between versions
> >
> >
> > What do you guys think?
>
> I like Gemfile.lock being ignored. I think the major benefit is that we find
> potential issues caused by new versions early. Also I think it's better to
> solve smaller issues continuously rather then one big issue during complete
> update. When you update too many gems at once it may be hard to see, what's
> causing which issue.
>
> --
> Marek
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>>> Hi.
>>> I'm experiencing a bit of a nuisance - we don't stage our Gemfile.lock in
>>> the git repo. This causes some annoying issues regarding gem versions. My
>>> latest issue was that the gem we use for LDAP changed the exception class
>>> it throws on an invalid lookup key (or something similar), in turn, this
>>> made some tests fail.
>>> This will keep happening unless we have Gemfile.lock for our project.
>
> Thanks for reporting the issue and keeping our stack up-to-date.
>
>>>
>>> Pros:
>>>
>>> 1. everyone uses the same gem versions, code works in expected ways
>>> 2. everyone remains sane.
>>> 3. Tom doesn't break his mac out of frustration, and won't need to
>>> explain broken mac to his manager
>
> <trolling>Not sure if broken mac is pros or cons </trolling>
>
>>>
>>> Cons
>>>
>>> 1. a bit more work, as staging Gemfile.lock means some merge conflicts
>>> once in a while.
>>> 2. will need to have a few Gemfile.lock files, one for each minor ruby
>>> version (1.9, 2.0, 2.1 and 2.2), as some gems differ between versions
>>>
>>>
>>> What do you guys think?
>>
>> I like Gemfile.lock being ignored. I think the major benefit is that we find
>> potential issues caused by new versions early. Also I think it's better to
>> solve smaller issues continuously rather then one big issue during complete
>> update. When you update too many gems at once it may be hard to see, what's
>> causing which issue.
>
> +1 for not keeping the Gemfile.lock: I prefer debugging and fixing the issues that appear every now and then
> in developers setup, and learning about the potential incompatibilities
> than doing all of that at once (or worse not doing so as well and ending up
> with obsolete versions of the packages). If there is a known constraint on
> some version, IMO it should be explicitly stated in the Gemfile (ideally
> with a link to an issue describing the problem). It should be in our intention
> to keep our stack up-to-date.
I agree entirely. We recently did a large update when dropping Ruby
1.8.7 support which has put us onto a very good footing. It was a lot
of work, and not something that I'd want to go through regularly.
Regular small issues are much easier to deal with.
> Another thing is Gemfile.lock plays no role in production environment,
> where the pacakge repository is the authoritative source of truth
> for which versions will be used. For me another reason to keep
> the version constraints more explicit, the doing so implicitly with Gemfile.lock.
The RPMs we ship differ somewhat from the gems used in a source
installation, so we have to be mindful that we can't dictate a list of
precise version numbers. I'm continuously working to reduce the gap
between our repos, OS repos and our source installation, which helps us
at least encounter the same bugs in all environments, but we need to
live with some flexibility.
···
On 26/01/15 09:29, Ivan Necas wrote:
> ----- Original Message -----
>> On Sunday 25 of January 2015 04:49:14 Tom Caspy wrote:
Great idea, I've updated test_develop_pr_core, test_develop and
test_plugin to start archiving it.
···
On 26/01/15 09:32, Ivan Necas wrote:
> I would however suggest one thing that might be helpful and includes the Gemfile.lock:
>
> Then running tests in the Jenkins, we could store the Gemfile.lock that was used there
> as a build artifact: so that, when experiencing some issues locally, one could grab the Gemfile.lock
> from some passing tests and test if that might or might not be an issue with a gem update.
> From running a diff on the Gemfile.lock, one could that easily notice the version changes
> that might potentially identify the root of the problem
+1 and I like the idea of keeping Gemfile.lock from successful test runs
in Jenkins.
M.
···
On 01/26/2015 10:29 AM, Ivan Necas wrote:
>
> +1 for not keeping the Gemfile.lock: I prefer debugging and fixing the issues that appear every now and then
> in developers setup, and learning about the potential incompatibilities
> than doing all of that at once (or worse not doing so as well and ending up
> with obsolete versions of the packages). If there is a known constraint on
> some version, IMO it should be explicitly stated in the Gemfile (ideally
> with a link to an issue describing the problem). It should be in our intention
> to keep our stack up-to-date.
>
> Another thing is Gemfile.lock plays no role in production environment,
> where the pacakge repository is the authoritative source of truth
> for which versions will be used. For me another reason to keep
> the version constraints more explicit, the doing so implicitly with Gemfile.lock.
>
> -- Ivan
>
</trolling>