Validation of cookbooks and it's dependencies using knife

Hello everyone,

Is there an established way that the chef community is following to validate all cookbooks & it’s dependencies against the current versions on the chef server before uploading the new versions?

I’m basically looking for a way that would validate all or a subset (specified by a pattern) of my local cookbooks, ensuring all dependencies are satisfied for each cookbook and maybe evening notifying when certain cookbooks have changed but the versions haven’t been updated before uploading the cookbooks to the server.

By validation, do you mean that all dependent cookbooks are present in the
knife cookbook upload will fail is any of the dependency cookbook
(defined in metadata) is absent in the chef server. Chef server or knife
does not check circular dependency etc.

Yes, doing the validation of the dependent cookbooks present is one part. And it is good to know that the knife cookbook upload will fail when the dependencies are absent on the server. But how do you handle the cases when the cookbook changes due to addition/removal/editing of a file from the cookbook, or the metadata changes? Is there something that could validate that in such cases the cookbooks versions should be changed before attempting to upload the cookbook?

I was looking for more of a knife validate command that would validate a given set of local cookbooks before attempting to upload them to the server.

Is there an established way of doing such validations? The --freeze flag when uploading cookbooks would ensure that the cookbook can’t be changed without updating the version, but a validate command before even getting to the upload would help figure out which cookbooks need a version update.

Dude, I am not getting the question, are you talking about who or how semver semantics is enforced? Most cases version bumps are manual and authors decide it. For automation if you are planning to do this from CI then you have to implement this by yourself. I have heard of knife spork, but never used it. I am not ware of any knife feature that will check the changed semantic and recommend version changing.

For most of the community cookbook, I enforce the version manually, they are one cookbook each repo. At PagerDuty, where all the custom cookbooks are in mono-repo, we enforce all internal cookbook a single version[1], and our tooling deletes any other version. This is to enforce master based deployments (master is gold), backed by CD (using GoCD). So we dont have this issue for the mono-repo style cookbooks.

Sorry for the confusion, yes, we are trying to enforce the validation of cookbook versions from the CI and even locally before pushing any cookbook changes. The way we are working right now is that we have all cookbooks in a single repo, we make changes to cookbooks and then have to manually bump up the versions every time we change it.

We’ve written a validate script, that compares the local metadata with metadata of the cookbook on the chef server, prints out any cookbooks which have changed, but versions haven’t been updated and the script errors out if it finds any such cookbooks. Now I’m wondering if it would make sense for knife to do such checks. I can try to get a PR to demonstrate the kind of checks we are doing so that should hopefully clarify some of the things we are trying to do.

I imagine having a knife validate command that compares the cookbooks versions with remote and whether it’s dependencies have been satisfied and are available.

I haven’t looked at knife spork or pd-sync-chef yet so thanks for sending those links. I will take a look at them shortly. But I was looking at thor-scmversion[1] and seeing if it would be possible to bump the cookbook version on every commit from the CI based on an article I was reading[2]. If we do this then we would potentially not require to manually bump the versions at all, but would end up uploading the same cookbook to the chef server even if the version hasn’t changed and would require to check-in the cookbook version as well from the CI.