[RFE] Promotion flag

[mjudeikis]

We have use cases where we want to build images with container image tags corresponding to git tags.
Something similar as openshift-ansible used to do where we have release-vx branch, and multiple tags with vx.y.z on the repo.

As a post-commit job into a release branch, we would like to promote images to external namespace with those tags. Potentially in the future, these images would go into registry.access.redhat.io (I need to get familiar with the process here too).

Currently promotion.tag is hardcoded field in CI-Operator config.

We could add field like:
promotion.tag_command which would execute a custom command on our code repo (in example make target) to define tag value for a particular promotion. Each of our release commit has to have marker file with version, so the command would just use it.

Before I jump into implementation details, wanted to start a discussion on this.

@stevekuznetsov @droslean @petr-muller WDYT?

[droslean]

There is a different ci-operator config for each branch already. Ci-operator will promote the images that have been tagged in the config in the images.to field. You should make sure that the tags are different between your branches to avoid overriding the images.

[mjudeikis]

Yes, and tag should be dynamically built/generated. In our case we would prefer it to be git tag based. But to accommodate wider use cases we might want to add something like command or resolved where we define how to define the unique value

[droslean]

Even that this idea is nice to have, we don't want to force our stakeholders to use git tags for promoting their images. Hence the logic of the separated config files for each repo.

[mjudeikis]

It should be something like tag_postfix field or something like that, which would be optional.
All this functionality should be optional, sale as test secret.

[smarterclayton]

So most of this behavior is going to be controlled by either the thing that controls the release payload (release new) or the thing that builds your OLM operator (OSBS pipeline). In both cases you won't be the one setting the version in the code, the build infrastructure will.

For core components the internal version will be ignored and not reported to end users - each image already tracks the source code it includes and we have tools that make extracting code from the payload easy.

[mjudeikis]

@smarterclayton this is all fine if we are talking about v4 world. This would serve for OSA build pipelines, where we need to control version in the code as a part of release payload to MSFT. But for this we need to be aligned with ART and OSA/MSFT requirements. Everything is still in the air how it will be done and we have a call today to discuss this (OpenShift on Azure call). Just probing all possible options here.

[mjudeikis]

/cc @y-cote @jim-minter