Fly using wrong image when pinning to a sha256 hash

Hello there, I’ve setup a github action to deploy to fly when I alter my fly.toml to deploy vaultwarden/server

I was using a sha256 digest to make sure that my build is reproducible. For example I set a tag for the testing-alpine image in my fly.toml

[build]
  # https://hub.docker.com/r/vaultwarden/server/tags?name=testing-alpine
  image = "vaultwarden/server@sha256:b13cbb632ce302060194eed750020a2bd922ee9b7bb74431ad56c33dc04ec869"

However, instead of using that digest, fly picks another one entirely to deploy, presumably in alphabetical order

2021-09-21T19:49:27.4671567Z Searching for image 'vaultwarden/server@sha256:b13cbb632ce302060194eed750020a2bd922ee9b7bb74431ad56c33dc04ec869' locally...
2021-09-21T19:49:27.4698277Z Searching for image 'vaultwarden/server@sha256:b13cbb632ce302060194eed750020a2bd922ee9b7bb74431ad56c33dc04ec869' remotely...
2021-09-21T19:49:27.6209077Z image found: img_x2wokpyd5mkp3g1m
2021-09-21T19:49:27.6222322Z Image: registry-1.docker.io/vaultwarden/server@sha256:0b1f2fb777d002ce91fc51de5be3dd13ae05e540668eea7a18c6c79f38b2e1bf

This seems like a bug, unless there is a different way to specify a hash for docker images

Hey @kurt, any ideas?

1 Like

I see the discrepancy in our logs but I can’t reproduce it. Are you still having the issue? I’ll keep digging and see if I can figure out what happened and post an update.

@trevor we just deployed a fix. It was a caching issue that would sometimes pickup the “latest” label when you actually passed in a digest.

1 Like