- 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
- [chef] RE: Can't bootstrap windows node after upgrading to ChefDK v4. (Please help! Windows platform), (continued)
[chef] Re: Re: Re: Berksfile.lock commit in dev branches, William Jimenez, 02/13/2015
[chef] Re: Re: Re: Berksfile.lock commit in dev branches, Xabier de Zuazo, 02/14/2015
Archive powered by MHonArc 2.6.16.