Add job for updating docker images for repository integration-k8s-kind

[denis-tingaikin]

Description

Each cmd-* application should be able to automatically updating the version of the docker image for integration-k8s-kind repository.

Solutions

Currently, we have two possible solutions:

1. Each cmd-*. application can create separate PR into integration-k8s-kind repository.
2. Each cmd-*. application can commit changes of docker image into a special branch. For example, use-case could be next:
   2.1. sdk repo has been updated.
   2.2. cmd-*. repos have been updated.
   2.3. cmd-*. repos provides a commit into branch integration-k8s-kind/cmd-update-%v where %v is changed gomod version.
   Note1: for option2 each commit into branch integration-k8s-kind/cmd-update-%v should cancel the previous build on this branch. For this, we can use
   https://github.com/marketplace/actions/cancel-workflow-action#usage
   Note2: In case when cmd-*. app is updated by the developer's PR then will be created separate PR into integration-k8s-kind repo as it prosed in option1.

[denis-tingaikin]

@edwarnicke What option we can start?

[edwarnicke]

I forsee some difficulties with Option 1. PRs created by the GITHUB_TOKEN of a cmd-* repo will not have access to any of the secrets of an integration-k8s-* repo. I suspect that means Option 2, unless you have a really clever idea for Option 1 :)

As to the branch naming... aren't the branches named in other places update/* ?

It might make sense to name the updates integration-k8s-kind/update/${name of repo pushing update} ?

Or am I misreading what you mean by %v?

[denis-tingaikin]

Or am I misreading what you mean by %v?

@edwarnicke
%v means

1. If has been updated sdk version in go.mod then %v is changed sdk version
2. Else it is repo name

[edwarnicke]

Or am I misreading what you mean by %v?

@edwarnicke
%v means

1. If has been updated sdk version in go.mod then %v is changed sdk version
2. Else it is repo name

Ah... I see where you clearly said that above, what were your thoughts on handling branch proliferation for that?

[denis-tingaikin]

@edwarnicke Nice catch :) I think we can just remove the brach in case of updating from SDK right after merge.

[edwarnicke]

@denis-tingajkin Can we figure out from a merge job which branch it was merged from?