Support version constraints for Git-sourced cookbooks

[kenny-evitt]

In this (long) comment I mentioned realizing that this kind of dependency specification in my Batali file doesn't work:

cookbook 'postgresql', '= 0.16.1', git: "https://github.com/phlipper/chef-postgresql.git"

I'm guessing it's because there's no obvious way to download specific versions from a Git repo. But I think using tags matching certain typical patterns, like 0.1.2 or v1.2.3, would work nicely; something like this regex could work.

If Batali could use tags as info about available versions then one could specify version constraints strictly in metadata.rb, for cookbook repos, and easily depend on versions earlier than the current version of the Git repo reference itself. And version constraints in Batali files, for infrastructure repos or other repos without a metadata.rb file, could reference any version for which a corresponding tag is available from the Git repo.

[kenny-evitt]

The console output I got when running batali resolve for a repo with the dependency spec example above:

[Batali]: Loading sources... [Batali]: Loading Batali file from: /Users/kenny/@code/myinfrastructure/Batali
[DEBUG]: Cache directory to persist cookbooks: /Users/kenny/.batali/cache
complete!
ERROR: Gem::Requirement::BadRequirementError: Illformed requirement ["{\"git\"=>\"git://git@github.com:phlipper/chef-postgresql.git\"}"]

[luckymike]

If the repo uses tags, you can use ref:

cookbook "postgresql", git: "https://github.com/phlipper/chef-postgresql.git", ref: "0.16.1"

But that doesn't get you all the way to what you're after. The chef server source is designed to handle this scenario, as the server offers an endpoint to retrieve any available cookbook version.

It might make work to attempt to resolve a tag ref when a version is passed, as you suggest, but I'm not sure offhand how much complexity that adds.

[chrisroberts]

Hi! Version constraints on cookbooks sourced via git is not supported and I don't plan on adding support for it. I have previously investigated this functionality but it is very fragile and slow. Batali ends up in a situation where it must impose assumptions about a repository and those assumptions may not be valid. Checks can be added for the assumptions but this in turn adds more complexity, compounded by the fact that it will be a source of constant change to attempt support for n number of styles.

So this is why the git source remains simple. I would argue that using a git source should really only be for testing/development and that really your cookbooks should all be released assets available via a store like supermarket or the chef server itself (referenced a bit in my response in #66).

What @luckymike mentioned above is likely what you are looking for with regards to the git source. Version constraint information is not valid when a git source is used as that source can only reference a single cookbook version. As such, when a git source is used, the version defined within the metadata results in the pinned version.

Hope that helps. I'm closing this issue but if you still have questions feel free to respond here.

Cheers!

[kenny-evitt]

@chrisroberts What about implementing a 'fake supermarket' provider that would map cookbook versions to Git repo tags?

Do you have or remember any details about what particularly was fragile or slow about this for Git sources? I also can't think of any assumptions that would need to be made about a repository that wouldn't also potentially apply to different versions of a cookbook in a Chef server or a supermarket.

Please let me know if you're just not interested in this. I can certainly maintain my own fork of Batali if I really want to. I'd prefer contributing directly, but this definitely doesn't seem to be an entirely natural fit.