Command 1: uses --image-label latest, seems to pull cached/older image and doesn’t reflect my latest changes in code
Command 2: fresh build with unique deployment ID, my deployment shows the latest code changes
Both run from same directory/commit/branch. Command 1 was working correctly for months, then suddenly started deploying stale code. I suspect that the --image-label latest is now causing it to reuse an older tagged image instead of building fresh.
FYI, the --image-label is supposed to allow me to name my image “latest“. I’m doing this because I use fly cron-manager from another app, and I have to reference the latest build image directly, without having to specify its id each time. So i’m labelling it.
Anyone else run into this recently? Did something change with how Fly handles image labels in remote builds?
Yes, we did make some registry-related changes this past week, see Faster, more reliable image deploys for all remote builders for some general details. It’s possible that mutable tags (like latest) that are overwritten aren’t matching their original expected behavior.
Thanks for reporting this issue, we’ll look into this and if it is a registry issue, hopefully restore the original mutable-tag behavior soon. In the meantime, you can try a deploy with the --depot=false flag (legacy builders don’t currently use the same registry optimizations) to see if that still works as expected for you.
I think I encountered this issue, or maybe it’s slightly different. Can you revert or fix the change that prevented large images (but within limit) from successfully deploying.
Hi @gkpo, we’ve rolled out a potential fix for this issue, give it another try and let us know if it’s working for you again. Thanks again for the report and sorry for the inconvenience to your workflow!
thanks so much