Get the sha of the currently deployed docker build

1

I’m naively thinking of having our CD deploy step check to see if it needs to update, the thought would be:

docker build .
docker inspect --format {{.Id}} image
flyctl (somehow get current deployed sha)
(check if sha’s are different and if so, deploy)

I’m curious if there’s any support with flyctl for step 3?

2

There isn’t right now but we can add that at least to the json output

1 Like
3

In theory, if you deploy the same sha, it’s a noop. So you may not need to make this optimization!

4

Totally, this would more as a time saving for CI.

5

I’m doing exactly this and was happy to see that updating the image with the exact same tag is indeed a no op. One thing I’m curious though is, what’s your default image pull policy for e.g. latest tags? As I’m not sure if and when you pull a new image using latest, I’ve opted to use a sha instead to make the version explicit.

6

On reflection, I think this is mostly tied to some troubles getting deploys to run consistently. For both hasura and postgres-ha, it’s not uncommon for the exact same config to, for whatever reason, to never signal to the server to update, which causes them to just hang. When it does succeed I can see it’s idempotent.

One interesting note on this mornings troubles with getting postgres-ha to deploy is the deploy says “Release v0 created” when in fact it’s on v17. After which it just sits there waiting for something to happen, but on the server/logs I don’t see anything happen.

7

We resolve an image tag to a sha at the time of deployment so you’re not silently upgraded.

This is a bug. When a deploy doesn’t trigger a release the API returns a nil value which is incorrectly mapped to an empty go struct. I’ve made a note to get that fixed this week.

8

This is a bug. When a deploy doesn’t trigger a release the API returns a nil value which is incorrectly mapped to an empty go struct. I’ve made a note to get that fixed this week.

Ah, makes sense. It ends up not exiting as well which prevents the deploy from finishing, but good to know in fact it’s actually detecting a non-release and just not handling on the cli side. Thank you.