Open kamaradclimber opened 10 years ago
What version of Berkshelf?
3.1.4
I think this is a bug we've talked about a few times but never actually came up with a resolution. The problem is that we try to be helpful and run install
before you upgrade. This causes a rewrite of the lockfile. But I could have sworn we fixed it... @reset?
yes indeed, berks install
suffer from the same behavior.
I suppose the desired behavior could be to modify only cookbooks in the group, their dependencies as well and ignore the rest of the lock file.
@kamaradclimber well with berks install
that is the expected behavior. Berkshelf should not graph things you do not have installed. Bundler behaves the same.
I meant the desired behavior for update
but I agree with you
@sethvargo do you think I can help with this issue?
I guess a fix would be to avoid install
when --only
is specified, would you consider a PR for that ?
@kamaradclimber that's the idea. I think in upload we do something like that. @skottler is also looking to get involved, so maybe you two could work together?
also having a similar problem with 3.1.5. after removing lock file and running berks install, i'm getting the following when running "berks outdated": "The lockfile is out of sync! Run berks install
to sync the lockfile."
i ran into "The lockfile is out of sync! Run berks install
to sync the lockfile" , so I googled it and landed here.
We are somewhat new to berks, so maybe it comes down to how we should be using it. In any case, our situation is we use separate git repos for our internal cookbooks (which could be a wrapper of some community cookbooks). So our Berksfile has:
cookbook 'A', git: 'git@github.com:org/A.git'
cookbook 'B', git: 'git@github.com:org/B.git'
Lets further assume B depends on A, such that in the metadata.rb of B:
version '0.0.1'
depends 'A', '= 1.0.0'
In our role, we have roleB to run "recipe[B@0.0.1]" , and roleA to run "recipe[A@1.0.0]" ; all happy.
But now we want to make change in A, but instead of modifying 1.0.0, we bump the version to 1.0.1 , modify the recipe in cookbook A, and make roleA to run "recipe[A@1.0.1]" . We don't want roleB to be impacted, ie it should continue to run cookbook B@0.0.1 that depends on cookbook A@1.0.0 . We push the change in the cookbook A github repo (master branch), and run berks update
But berks update fail with dependency error. Basically saying B needs A at 1.0.0, but A is 1.0.1... We then try to do berks update -o A
, that makes the update successful (checked the ~/.berkshelf/ directory for the latest) ; but upon berks install, it failed with the lockfile out of sync.
Before berkshelf, we basically have a single github repo of chef with all the cookbooks in it, but run into the problems as highlighted in why use berksehlf... But how do we handle the above scenario? How do I upload the new version of the cookbook A, without forcing cookbook B to depends on the new version of A?
bump?
Is this already fixed or anybody working on this issue? I had the pretty errors as @neurogenesis.
I edited Berksfile.lock
so that it can sync with the latest revision of cookbook hosted on github, and then try to update Berksfile.lock
with berks vendor
and then berks verify
and comes out the error saying The lockfile is out of sync! Run berks install to sync the lockfile.
I have no clue, can anybody help ?
I got this error and clearing the cache resolved this for me.
rm -rf ~/.berkshelf/
I have defined several groups into my Berksfile (community and internal_core, internal_wrappers…) and I'd like to update all cookbooks in internal_core group.
My guess would it be to
berks update --only internal_core
but this remove all traces from other cookbooks in Berksfile.lock.Is this a bug ?