Lockfile Support #173
Comments
|
For Puppet and Chef, there is similar tooling available and there's already support in Pulp for puppet modules:
A useful function is Then you can update individual modules with |
|
Just noting that of all the questions I get in my day-to-day Ansible work, this is one that comes up quite often ("does Ansible Galaxy have any concept of a lock file?"). I'm assuming with mazer and the new depsolver, it would be a lot easier to implement this sort of functionality. |
|
You are correct @geerlingguy. It does not. Mazer is intended to be a content package manager and will need a lock file mechanism amongst other features. |
alikins
added
help wanted
|
There may be a very limited subset of this added for 1.0. Planning on adding something similar to ansible-galaxy's -r/--role-file support. Probably something along the lines of a cli flag to point to a yaml file that has a dictionary But I think that should cover a lot of the use cases. |
Add support for 'collection lockfiles'. A collections lock specifies a set of collections to install and the version specs to match. Fixes ansible#173 Add collections_lock and collections_lockfile models. Add ansible_galaxy.collections_lockfile with a yaml loader for a collections lockfile. Update cli and install action to use the collections lockfile. The contents of collections lock file is a yaml file, containing a dictionary. The dictitionary is the same format as the 'dependencies' dict in galaxy.yml. ie, The keys are collection labels (the namespace and name dot separated ala 'alikins.collection_inspect'). The values is a version spec string. ie "*" or "==1.0.0". Example contents of a collections lock file: alikins.collection_inspect: "1.0.0" alikins.collection_ntp: ">0.0.1,!=0.0.2"
Add support for 'collection lockfiles'. A collections lock specifies a set of collections to install and the version specs to match. Fixes ansible#173 Add collections_lock and collections_lockfile models. Add ansible_galaxy.collections_lockfile with a yaml loader for a collections lockfile. Update cli and install action to use the collections lockfile. The contents of collections lock file is a yaml file, containing a dictionary. The dictitionary is the same format as the 'dependencies' dict in galaxy.yml. ie, The keys are collection labels (the namespace and name dot separated ala 'alikins.collection_inspect'). The values is a version spec string. ie "*" or "==1.0.0". Example contents of a collections lock file: alikins.collection_inspect: "1.0.0" alikins.collection_ntp: ">0.0.1,!=0.0.2"
Add support for 'collection lockfiles'. Add 'list --lockfile' to output a collections lockfile to stdout. A collections lock specifies a set of collections to install and the version specs to match. Fixes ansible#173 Add collections_lock and collections_lockfile models. Add ansible_galaxy.collections_lockfile with a yaml loader for a collections lockfile. Update cli and install action to use the collections lockfile. Update README.md with lockfile info To reproduce an existing installed collection path, use like: mazer list --lockfile > collections_lockfile.yml mazer install --collections-path /tmp/somenewplace --collections-lock collections_lockfile.yml To create a lockfile that matches current versions exactly, add the '--frozen' flag: mazer list --lockfile --frozen Example output for `mazer list --lockfile`: alikins.collection_inspect: '*' example.foobar: '*' Example output for `mazer list --lockfile --frozen`: alikins.collection_inspect: ==1.2.3 example.foobar: ==0.0.9 The contents of collections lock file is a yaml file, containing a dictionary. The dictitionary is the same format as the 'dependencies' dict in galaxy.yml. ie, The keys are collection labels (the namespace and name dot separated ala 'alikins.collection_inspect'). The values is a version spec string. ie "*" or "==1.0.0". Example contents of a collections lock file: alikins.collection_inspect: "1.0.0" alikins.collection_ntp: ">0.0.1,!=0.0.2"
Add support for 'collection lockfiles'. Add 'list --lockfile' to output a collections lockfile to stdout. A collections lock specifies a set of collections to install and the version specs to match. Fixes #173 Add collections_lock and collections_lockfile models. Add ansible_galaxy.collections_lockfile with a yaml loader for a collections lockfile. Update cli and install action to use the collections lockfile. Update README.md with lockfile info To reproduce an existing installed collection path, use like: mazer list --lockfile > collections_lockfile.yml mazer install --collections-path /tmp/somenewplace --collections-lock collections_lockfile.yml To create a lockfile that matches current versions exactly, add the '--frozen' flag: mazer list --lockfile --frozen Example output for `mazer list --lockfile`: alikins.collection_inspect: '*' example.foobar: '*' Example output for `mazer list --lockfile --frozen`: alikins.collection_inspect: ==1.2.3 example.foobar: ==0.0.9 The contents of collections lock file is a yaml file, containing a dictionary. The dictitionary is the same format as the 'dependencies' dict in galaxy.yml. ie, The keys are collection labels (the namespace and name dot separated ala 'alikins.collection_inspect'). The values is a version spec string. ie "*" or "==1.0.0". Example contents of a collections lock file: alikins.collection_inspect: "1.0.0" alikins.collection_ntp: ">0.0.1,!=0.0.2"
Original issue is abandonded in archived galaxy-issues project
The related issue about versioning of roles is migrated: ansible/galaxy#83
I recreated this issue in ansible-galaxy and now here.
Original issue by @geerlingguy
It would be helpful if Ansible Galaxy supported a 'lock' file.
When running
ansible-galaxy install -r requirements.yml, Ansible Galaxy could create arequirements.lockfile (or some other name) that stores the following metadata for each downloaded role:Then, if running the command
ansible-galaxy install -r requirements.ymlagain, it would install based on the exact identifiers in the lock file.The details could be a little different, of course, and we'd need a command like
ansible-galaxy update -r requirements.ymlto update an existing lockfile... but this would make idempotent playbook configurations much easier for many projects without requiring all downloaded roles be stored in the project repository (e.g. like Drupal VM currently does).Other examples of lock file support:
Original Request
For Drupal VM, we've decided to pin our requirements.yml file's role requirements to specific versions (e.g.
3.0.1,2.5.0, etc.).It would be nice if we could support some method of semver with role versions (instead of just requiring a branch or tag... and maybe this is related to/duplicate of #70), where you could specify a dependency in requirements.yml like:
When galaxy picks the tag to pull, it would check for any in the 1.7.x range, and choose the latest release. That way I don't have to spend so much time maintaining all my requirements files for various projects.
I would love to see something as involved as Composer's Version support, but I know that's a bit of a moonshot. It would be nice to have a lock file that would set the versions currently installed, too, as that would even allow me to set
masterbut lock in the versions at a specific point in time.Anyways, I was just thinking about how awesome it is to point at tagged role releases in terms of keeping one's playbook completely idempotent and stable—yet how annoying it is to have to manually tinker with the
requirements.ymlfile so often.The text was updated successfully, but these errors were encountered: