When taking over dev, developers will often want to redeploy with only a configuration change but not rebuild the images.
How should we support this? In particular
How should we keep track of what images to use when not matching source commit?
How should users invoke hydros to indicate don't rebuild images
There are two ways I can think of doing this
Use .lastsync.yaml to keep track of the most recently built images and use those in the event we don't want to rebuild
Add a command line flag to hydros takeover command to indicate that images shouldn't be rebuilt.
Use a different kustomize overlay that tracks the images to use and a separate ManifestSync
I prefer 1 because its less overhead. Developers can easily toggle between reusing/rebuilding the images with a flag e.g "--rebuild-images=false".
If we go with 2 then we haven't addressed making it easy for developers to update the pinned images. This would involve multiple command line tools; e.g. gcloud, yq, kustomize. This isn't a great experience. 1. should hopefully eliminate the need to use make to glue together different tools.
1 isn't inconsistent with 2. Having separate overlays may make sense if there are certain options you always want to enable in the takeover deployment; e.g. enabling debug logs. An overlay makes sense if
The changes are distinct from what should be deployed in the case of sync'ing main to dev
The options rarely need to be updated
The second bullet point doesn't hold in the case of the images as developers will frequently want to toggle between building and not building them. So it makes to have special logic for that case.
When taking over dev, developers will often want to redeploy with only a configuration change but not rebuild the images.
How should we support this? In particular
There are two ways I can think of doing this
Use
.lastsync.yamlto keep track of the most recently built images and use those in the event we don't want to rebuildhydros takeovercommand to indicate that images shouldn't be rebuilt.I prefer 1 because its less overhead. Developers can easily toggle between reusing/rebuilding the images with a flag e.g "--rebuild-images=false".
If we go with 2 then we haven't addressed making it easy for developers to update the pinned images. This would involve multiple command line tools; e.g. gcloud, yq, kustomize. This isn't a great experience. 1. should hopefully eliminate the need to use make to glue together different tools.
1 isn't inconsistent with 2. Having separate overlays may make sense if there are certain options you always want to enable in the takeover deployment; e.g. enabling debug logs. An overlay makes sense if
The second bullet point doesn't hold in the case of the images as developers will frequently want to toggle between building and not building them. So it makes to have special logic for that case.