search

willhallonline / docker-ansible

Ansible inside Docker containers: Alpine, Ubuntu, Rocky & Debian with Ansible 2.16, 2.15, 2.14, 2.13, 2.12, 2.11, 2.10 and 2.9 + Mitogen
https://www.willhallonline.co.uk/project/docker/docker-ansible/
MIT License
392 stars 137 forks source link

Request: Immutable tags on docker hub #42

Closed InterFelix closed 2 years ago

InterFelix commented 3 years ago

I use this image for a GitLab CI/CD pipeline in conjunction with matrix_docker_ansible_deploy, a comprehensive playbook for installing a Matrix homeserver. The last update of this image has bumped the ansible version in willhallonline/ansible:2.10-ubuntu20.04 from 2.10.12 to 2.10.15, which has broken the execution of this playbook, and I have no way of using an older version of this image, since there are no immutable tags I could pin the docker image at. Therefore, I request immutable tags to be added, like "2.10.15-ubuntu20.04" in addition to the usual "2.10-ubuntu20.04".

goetzc commented 3 years ago

I have been affected by this too, it broke CI workflow.

Looks to me that this commit is the culprit https://github.com/willhallonline/docker-ansible/commit/32998c72395962e06c9b38740da92bb6db24bbbf

@willhallonline as this removed packages from the Docker image, it a breaking change on the same image tag. I think the change should be reverted. Many workflows might be affected.

thaarhoff commented 3 years ago

Same for our project. Without notice our Gitlab CI broke.

InterFelix commented 3 years ago

Maybe try using devture/ansible . It's based on Alpine Linux though, so depending on your setup, you might have to adjust your CI/CD-Scripts. Also, it's on Ansible 2.9, but at least it has immutable tags.

willhallonline commented 2 years ago

I am sorry about this. At the moment, I am not doing immutable tags, mainly because of the burden of managing multiple OS/Ansible combinations (about 33 at the moment) and increasing that would just take more work. I do intend to move the Ansible version install to be a variable though which would resolve some of these problems (or at least make it easier to build and own).

willhallonline commented 2 years ago

@InterFelix, @goetzc, @thaarhoff : what versions would you like as immutable? I want to keep rebuilding the containers on a stable base image, however, have now implemented that I could release different Ansible versions as required? Or is it rather that you would like to maintain every version of Ansible?

InterFelix commented 2 years ago

What I was initially thinking was "just add a tag with the minor version on release", so when an image gets built with Ansible 2.10.12 for example you can directly refer to it by its version. Now it basically gets overwritten by a new minor update of Ansible 2.10 without any way of referring back to the image that contained 2.10.12 as the minor version.

The underlying problem is that a minor update broke compatibility in my case, which shouldn't ever happen, but it did, but that's Ansible's fault, not yours.

willhallonline commented 2 years ago

I could probably now relatively easily do that (easier than it was before my new changes)... So rather than willhallonline/ansible:2.10-alpine-3.15 it becomes willhallonline/ansible:2.10.12-alpine-3.15?

Maybe I also keep willhallonline/ansible:2.10-alpine-3.15 which is rebuilt at newest all the time, but the old ones stay fixed (including older packages inside Alpine-3.15)?

InterFelix commented 2 years ago

That's exactly what I had in mind. Just put a tag that explicitly identifies the minor version on each image so there's a way to target a specific minor version.

willhallonline commented 2 years ago

This is completed now . I have created immutable tags within all OS from the latest Ansible version inside:

Inside tag v4.0.1.