Getting the release version from inside an Fly app

1

I don’t currently see a way to get the release version that flyctl deploy prints from inside the app itself. This would be useful for observability purposes.

2

For reasons that you shouldn’t have to worry about, this is a lot harder than it should be. Those version numbers can change without actually restarting the app instances.

You can set an environment variable at deploy time, however. Doing something like this might get you what you need:

flyctl deploy -e APP_REVISION=$(git rev-parse --short HEAD)

That will set the $APP_REVISION env variable to the short git revision number.

2 Likes
3

Thank you, that’s exactly what I ended up doing.

1 Like
4

Can this be a setting added to the toml file? or something done automatically if it theres a .git directory?

5

We use a deploy wrapper and a build time argument in our Dockerfile.

Here are the lines in our deploy wrapper: dash/deploy at 1b2fcd793a6bc4077c4b13d7dc21bc5624dfe0ee · outstand/dash · GitHub

We use it with the following lines at the end of our Dockerfile:

ARG vcs_ref
LABEL org.label-schema.vcs-ref=$vcs_ref \
  org.label-schema.vcs-url="CHANGEME" \
  SERVICE_TAGS=$vcs_ref
ENV VCS_REF ${vcs_ref}
ENV APP_REVISION ${vcs_ref}
1 Like
6

I’m curious, in what circumstances can fly’s release version change without restarting the app? Weird corner case or somewhat common…?

Would love the original feature here. Some added context: In our other paas, the provider exposes the release number (similar to fly’s deploy number - a strictly increasing integer) in env.

What’s nice about this is it’s a simple roll-up for all of the app’s config, which we can then tag in crash reports (Sentry), customer bug reports, etc, to know what was going on. The git rev-parse approach would only capture code changes, so if someone borked SECRET_KEY or VIP_RATE_LIMIT, we wouldn’t know from the git sha alone.

1 Like
7

That’s an excellent point!

8

@kurt Do you have any plans for something like a metadata API (a la AWS)?