Automate deployment to Docker Hub

[Totktonada]

There is the proposal about the new release policy. In short: x.y.z docker tags become frozen.

The old process was quite simple: rebuild everything and push to Docker Hub. Now the process assumes pushing of a certain tag. When it is performed manually, it is easy to make a mistake (docker files are parametrized and you should choose correct parameters for each image). Let's automate the process of deployment to Docker Hub.

I propose to use a git tag (x.y.z or, say, x.y.z-r1) in this repository (tarantool/docker) to trigger deploy to Docker Hub under x.y.z or x.y.z-r1 docker tag (and update the corresponding rolling version tags, see the new release policy). We can push several tags that are point to the same commit.

As result we can easily find from which tarantool/docker commit a certain docker image tag was built. It is good for reproducibility and to understand what exactly is deployed to Docker Hub.

NB: What is better to do with 1.x-centos7 and 2.x-centos7, where we have no fixed versions?

Further idea from @avtikhon: When a tag is pushed to tarantool/tarantool repository, a CI job can push a git tag to tarantool/docker repository automatically.

[tsafin]

Using tags in tarantool/docker repository for triggering publishing to docker hub sound a little bit artificial. Using tags at the parent tarantool/tarantool looks much, much better and is a natural way to make artifacts of those repositories consistent.

[Totktonada]

AFAIR, we already discussed this and agreed to don't move the content of this repository to tarantool/tarantool. Instead, we'll develop 'clean' docker images (without modules and scripting around tarantool) within tarantool/tarantool repository and publish them based on tarantool/tarantool tags. It is the separate topic.

If you're about triggering a pipeline here from a tag pipeline in tarantool/tarantool, then, yep, it is doable. But it looks complex for me and, what is important, it will be hard to understand what exact commit from this repository is used to build a certain image:tag on Docker Hub.

Marking a commit to deploy using a git tag looks straight and transparent for me.

Or, maybe, I don't get your idea.

[tsafin]

If you're about triggering a pipeline here from a tag pipeline in tarantool/tarantool, then, yep, it is doable. But it looks complex for me and, what is important, it will be hard to understand what exact commit from this repository is used to build a certain image:tag on Docker Hub.

Yep, exactly this case - we are ready to publish some release in the tarantool/tarantool repository (i.e. we are about to release a.b.c tag, or just about to move a.b rolling tag, or anything like that)

then we trigger docker image release via CI. Which will create new set of docker tags, described to the policy.

NB: If we want to know which exact commit is corresponding to the docker image to be tagged, then we could additionally mark images with tag in a form a.b-XXXX-YYYY, where XXXX would be tarantool/tarantool commit hash, and YYYY would be tarantool/docker commit hash. Or something like that (i.e. tag is function of both commits at the same time: to the kernel, and to the docker repos)