Ansible Galaxy 'Lock' file support

Original issue is abandonded in archived galaxy-issues project The related issue about versioning of roles is migrated: https://github.com/ansible/galaxy/issues/83

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 a requirements.lock file (or some other name) that stores the following metadata for each downloaded role:

• Role name
• Role version or branch identifier used
• Specific git tag or hash downloaded

Then, if running the command ansible-galaxy install -r requirements.yml again, 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.yml to 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:

• Python pipfile
• Node.js yarn.lock file
• PHP composer.lock file
• Ruby Gemfile

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:

- src: geerlingguy.apache
  version: 1.7.*

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 master but 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.yml file so often.

[geerlingguy]

Related, but slightly different to this particular feature request: it would also be nice if we could allow version constraints for collections in requirements.yml and on the CLI, so I opened https://github.com/ansible/ansible/issues/68194. Finally, to allow upgrading of dependencies, it would be nice to have the ability to upgrade using ansible-galaxy: https://github.com/ansible/ansible/issues/65699

[AlanCoding]

ansible-galaxy collection verify and ansible-galaxy collection list were recently added and have some bearing on this. The verify command pulls the checksums from the server and verifies the installed version against that. The way I read this is that the lock file would contain those checksums, and could be validated against (interacting with the server is very slow). That also seems like a stretch goal, whereas producing versions (like the list command) and putting that into a valid requirements.yml file would take a short time to develop.