Berkshelf leaves modified files after run causing git merge issues

[wjimenez5271]

When using the berkshelf option with grocery-delivery, berkshelf will sometimes make changes to the Berksfile.lock on disk as a result of the berks update command. This causes a merge error for git next time grocery delivery runs. I've been working around it by doing a git reset after each run, but a more integrated solution would be better:

cd [repo-dir]
git reset --hard

[jaymzh]

How about adding Berksfile.lock to your .gitignore?

[wjimenez5271]

That would work. And another option is to ensure the Berksfile.lock is already up to date in your CD pipeline before it gets to grocery delivery. But if neither of these things are done, grocery-delivery will fail so I wonder if we should still make a provision for that situation. Or maybe not, perhaps its better to handle these things outside of grocery-delivery...

[odcinek]

Seems like for that particular workflow ignoring Berksfile.lock altogether is the right way to go. Since we're doing berks update it's useless to keep it around.

It might make sense to support both:

• do berks update and .gitignore Berksfile.lock
• do berks install and depend on Berksfile.lock being provided

[jaymzh]

So.. as Marcin pointed out, certainly with berks up, it makes no sense to have a lockfile in git.

While you could do bersk install it toally breaks the GD model and so I don't see us building that workflow.

So, to answer your question... I'm not sure how we would do that... perhaps in that PR you're going to do to add docs for how to use this with berkshelf you'll add the "you must add this to .gitignore"? Or perhaps we start passing in --ignore type flags to all our commands (less thrilled about that, but if they exist I'm not opposed to it).

Thoughts?

[jaymzh]

@wjimenez5271 ?

[wjimenez5271]

Sorry, got slammed at work this week.

So something else I've been considering, in some ways use of berks update is really inappropriate for grocery-delivery to be doing in the sense that it's domain is to ensure changes are propagated as defined by the state of the world in git, not resolve or otherwise render those changes (correct if wrong). Now in practice it is convenient for GD to do update since the run will still work even if the developer forgot to, and usually harmless as well.

So perhaps in the interest of usability, and per @odcinek's point, we want to offer both modes, with a strong preface of the risks associated with not using GD to do berks update and resolve dependencies. I'd be really curious to know what Jamie Winsor thinks about this, esp. since the use of Berkshelf in this manner isn't well documented. I happened to mention how we're using Berkshelf with GD at Chefconf this year and he was very supportive of the idea...but I'd certainly like some of his thoughts on specifics like this.

@jaymzh to your thoughts about implementation, I agree another cmd flag for this is undesirable. Maybe we just have an optional config param for berks mode that accompanies the berks related ones, something like strict and relaxed, the former being no berks update or install and requires a lockfile, and the later will run gratuitous berks update and will ignore the lockfile.

[jaymzh]

I can't see a sane way to make berks install ever work with GD - they are fundamentally different models. Using berks update to force dependency checking is fine, but you either want to be living off of head or you want to be locking sets of versions. Since we all at least agree that with berks update that .gitignore is the right call, I'm going to close this - and if we decide there is a sane usecase for berks install we can revisit then.