Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

berks apply command #473

Merged
merged 11 commits into from
May 7, 2013
Merged

berks apply command #473

merged 11 commits into from
May 7, 2013

Conversation

capoferro
Copy link
Contributor

Addresses #440

This adds the berks apply ENVIRONMENT command to Berkshelf.

ALL version locks will be applied to the target environment's cookbook_versions hash

⚠️ Note that this does not address if cookbooks are being pulled from a path or git source. Perhaps this should error out if path or git cookbooks are detected?

@reset
Copy link
Contributor

reset commented May 1, 2013

We should use Chef-Zero to handle these acceptance tests

@sethvargo
Copy link
Contributor

So I really like this, but I think berks lock could be confusing to users. Someone might think it generates the lockfile, rather than applying the locked versions to an environment. What about berks apply?

@ivey
Copy link
Contributor

ivey commented May 1, 2013

Concur with @sethvargo on berks apply

@reset
Copy link
Contributor

reset commented May 1, 2013

same here, I like berks apply

reset added 3 commits May 1, 2013 15:42
Berksfile will be installed before environment is attempted to be locked
add test coverage to apply function
@reset
Copy link
Contributor

reset commented May 3, 2013

@ivey @sethvargo @bluepojo updated to support the latest lockfile. Also modified the behavior slightly: the application of the lock will always include dependencies. From our architecture discussion the other day, this command makes most sense when you lock all dependencies to allow for some sort of "promotion" process across environments.

@capoferro
Copy link
Contributor Author

Makes sense to me. I waffled a fair bit on whether to default to dependencies or not. I ended up choosing not to cause I imagined this feature would mimic what a human would do to lock their dependencies (that is: lock only the top level), but I see why locking dependencies by default is reasonable.

@capoferro
Copy link
Contributor Author

👍

@sethvargo
Copy link
Contributor

I'm 👍 on this now.

reset added a commit that referenced this pull request May 7, 2013
@reset reset merged commit f06ecfe into master May 7, 2013
@reset reset deleted the berks_lock branch May 7, 2013 01:19
@berkshelf berkshelf locked and limited conversation to collaborators Jun 16, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants