[chef] Re: Re: Re: Re: Re: Re: Berksfile.lock commit in dev branches


Chronological Thread 
  • From: Torben Knerr < >
  • To: " " < >
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Berksfile.lock commit in dev branches
  • Date: Mon, 16 Feb 2015 07:27:59 +0100

Hi Xabier,

yes, I believe I had the `berks update` problem too. Removing the
Berksfile.lock before running `berks update` helped, but that's not
nice either. At this point I stopped the experiment since I have
mostly chef solo / zero requirements and so this was a problem I don't
have to solve now ;-)

Btw: one thing I did differently by intent was to use plain ruby regex
for parsing the Berksfile.lock, as I was not sure whether berkshelf
API is present wherever the metadata.rb is evaluated. But as you have
shown it seems to work on chef client / server that way too...

Cheers,
Torben



On Mon, Feb 16, 2015 at 12:47 AM, Xabier de Zuazo 
< >
 wrote:
> Hi Tobern,
>
> On Sun, Feb 15, 2015 at 09:52:42AM +0100, Torben Knerr wrote:
>> interesting to know. Yes, it's indeed a bit hacky and uncommon an so
>> on... I would probably do it that way if I were using Chef Server, but
>> for Chef Solo / Zero having the Berksfile.lock checked in is
>> fortunately enough.
>
> Yes, I loved your approach and try to use it instead of mine. But I ran into
> the problem that Berkshelf reads the Berksfile.lock to generate the
> Berksfile.lock and `berks update` did not work properly.
>
>> So do you use environments for environments then?
>
> Yes, sounds weird :-D
>
> Cheers,
>
> --
> Xabier de Zuazo



Archive powered by MHonArc 2.6.16.

§