What is the recommended way of dealing with image AND manifest as a bundle.
Sometimes one has image and a manifest as a bundle (i.e. this image won’t work on previous versions of the manifest, nor this manifest won’t work with older images)
Today I see that one can trigger on specific image OR artifact. That works most of the time. Yet every so often one introduces non compatible changes and really need to treat an image and manifest together. And I can’t see a way to do it.
What am I missing? maybe spinnaker has a way which I am not aware of. Or I approach the problem from the wrong angle?
What I was thinking:
- Jenkins creates an image AND a manifest… Pipeline should treat them as a bundle.
- Jenkins does above AND creates a manifest with a right image printed in. then all pipeline has to do is to take the manifest and use it with no substitution.
Trouble is in nigher #1 nor #2 manifests don’t have versioning/tags (at least I didn’t find). Thus if jenkins makes a new build, we have a new tagged image, but simply overrite the manifest on gcs. Thus have no way back. in case deploy actually fail.
jenkins can ship a manifest to gcs with say manifest_versionxxx.yml yet I don’t see in spinnaker a way to get to pick versions/tags same way I can do for images from the repo .
similar idea, jenkins can expose manifest as an artifact which can be accessed on per build number.(i.e. same way as properties exposed, yet passed later as a manifest)