Yes, I can generate a manifest with an image printed in. But then I have 2 problems
- If I generate deployment.yml and make it an artifact. all works. except that every jenkins build just overwrites this file. making it hard to rerun the pipeline.
- I can generate deployment_v1.0.2.yml and deployment_v1.0.3.yml but now I don’t know how to point pipeline to such manifest ( say it is on gs://my_bucket/deployment_v1.0.2.yml)
So in case of a jenkins build and associated property file or an image in a repository we can point to a general direction and the system figures out how to deal with versioning/tagging. Thus allowing us to trigger pipelines later and picking build (or image tag) we are interested in. I couldn’t find any functionality like this for manifest. Maybe I am just missing.
And as to where it might be useful: as I point out in this thread Every so often one changes manifest so much that it only works with a specific image. Since manifest is in git and image is build by jenkins based on the same git. one might as well treat them as a bundle. as an alternative, jenkins can generate a manifest with an associated image printed in (i.e. task as binding does today by deploy stage). but then we run into issue #2 above (at least I don’t know how to point to a general direction of the artifact and versioning will be taken care of by giving some regex or similar).
Of course, don’t get me wrong. manifest as an artifact and image binding is great! Just then I wired things together with jenkins generating an image and overwriting deployment.yml I realized that with this system we can only “roll forward”. in case image and manifest are out of sync. just press build again and hope they will be in sync again (and there is no way going back to “let me try image “n-3” and associated manifest. what exactly went wrong there”. since even if image is present, manifest is already only of version “n” ) . So started to brainstorm how this can be improved