We can have Jenkins handle the credentials, then we need to decide if either:

1. We come up with a way for "build-artifacts.sh" to ask Jenkins to publish the containers on its behalf (Probably either by tagging them in a certain way, or leaving some files in exported-artifacts). This is aligned with the way that Jenkins also publishes RPMs to resources.ovirt.org on the project`s behalf.

2. We make the credentials accessible to "build-artifacts.sh" somehow to let it publish on its own.

I also described this in my 1st comment above.

Publishing to public docker registry requires authentication and authorization so, if we don't want to store our organization password for docker hub in a plain text file in the automation folder, we need to handle the OAuth2 token for it.
Probably it would be better to use a ready to use plugin for that such as https://github.com/jenkinsci/docker-build-publish-plugin

That will limit us to post-merge builds only. I'd rather be able to publish pre-merge builds as well.

I think it also limits our choice of of container build tooling. (Only docker and Dockerfiles. But s2i and Ansible container are interesting no?)

Another option is to configure docker hub for automatic rebuilding from our github mirror on every merge.
https://docs.docker.com/docker-hub/github/

In this way we avoid pushing a lot of gigabytes to github but maybe we can loose a bit of control over the tagging process.

We need to decide where we publish the images and how will other jobs like OST will consume it.

It shouldn't really matter where we publish.

As I see it there are two main option to publish anything from standard CI:

1. Have build_artifacts.sh put it in "exported_artifacts" and then have "the system" publish it to where it needs to go - this is what the experimental flow is doing for example for RPMs.

2. Publish directly from build_artifacts.sh

It should be obvious that solution #2 is more flexible and will require less maintenance from us in the long run, but it has a couple of issues:

1. For publishing typically some credentials are needed

2. The decision where to publish ends up being made at the discretion of the developer, as opposed to on an environment level.

I don't think #2 is really an issue. WRT #1, this is something we've encountered before, and perhaps we should solve it by adding support for credentials and secrets in Standard CI ().