Currently a project containing quarkus-openshift are generating one BuildConfig and two ImageStream objects., even if we are using quarkus.openshift.build-strategy=docker.
When using this strategy, those objects are going to be created before the image building start (but they are not removed after it finish)
So, If we try to use the generated openshift.yaml later for a deployment, it is going to fail because they exists already.
Also, those building objects are not necessary for the deployment at all, so they should not be generated for this case.
As a workaround I'm generating the openshift.yaml at dev time and removing those object (also the RBAC objects since our namespaces are created containing service-accounts that we must use)
Description
Currently a project containing quarkus-openshift are generating one BuildConfig and two ImageStream objects., even if we are using
quarkus.openshift.build-strategy=docker
.When using this strategy, those objects are going to be created before the image building start (but they are not removed after it finish) So, If we try to use the generated openshift.yaml later for a deployment, it is going to fail because they exists already.
Also, those building objects are not necessary for the deployment at all, so they should not be generated for this case.
As a workaround I'm generating the openshift.yaml at dev time and removing those object (also the RBAC objects since our namespaces are created containing service-accounts that we must use)
Implementation ideas
No response