This issue refers to ROCKs api-server, visualization-server and persistenceagent. Those present a mismatch between the docker repository in which we push them (which is the same with the directory in which the code lies) and their corresponding name fields.
AFAIK, we have followed the implicit convention for all other ROCKs of having the name field match the code directory and docker repository what we push the image to. This way also, the produced .rock file has the same suffix as the image pushed to Docker.
Our ROCKs CI also has as a prerequisite that we will always use as an image name the rockcraft.yaml name field which resulted in pushing to different repositories for those 3 ROCKs (example https://github.com/canonical/pipelines-rocks/actions/runs/7542574951/job/20532252266). I went ahead and manually moved those to the repositories we already used for those ROCKs.
That being said, I think we should go ahead and edit those ROCKs name fields in order to avoid this from happening in the future and also making it easier to match between docker and code repo. We could also document this convention in our ROCK best practices spec.
This issue refers to ROCKs
api-server
,visualization-server
andpersistenceagent
. Those present a mismatch between the docker repository in which we push them (which is the same with the directory in which the code lies) and their correspondingname
fields.AFAIK, we have followed the implicit convention for all other ROCKs of having the
name
field match the code directory and docker repository what we push the image to. This way also, the produced.rock
file has the same suffix as the image pushed to Docker.Our ROCKs CI also has as a prerequisite that we will always use as an image name the
rockcraft.yaml
name field which resulted in pushing to different repositories for those 3 ROCKs (example https://github.com/canonical/pipelines-rocks/actions/runs/7542574951/job/20532252266). I went ahead and manually moved those to the repositories we already used for those ROCKs.That being said, I think we should go ahead and edit those ROCKs
name
fields in order to avoid this from happening in the future and also making it easier to match between docker and code repo. We could also document this convention in our ROCK best practices spec.