Supply build version via env variable

Questions / Help
1

When deploying new versions of my app I can get the Fly.io instance ID via the FLY_ALLOC_ID but there is no way for me to know what version of the app is deploying easily when using continuous deployments via things like GitHub actions.

The fly CLI tool gives me a nice version/release that gets created each time (ie messages like v81 deployed successfully). It would be fantastic if this was supplied to the deployments as well so it can easily be printed via logs or something.

Thanks for fly though! Its absolutely fantastic and a real joy to deploy apps to!

2 Likes
2

This is tricky for reasons you shouldn’t have to worry about!

Are you just trying to get a sense of what code is running? I know several people set an env variable from a git revision at deploy time. If that’s helpful, you can run something like:

fly deploy -e GIT_REVISION=$(git rev-parse --short HEAD)

We could almost just do this by default, I guess! It would make some sense to have that happen magically.

3

This works - but with this approach you wouldn’t know if a release were generated by a secret being changed.

1 Like
4

The git commit is a good idea! As @jsierles mentions this doesn’t cover all situations but is a good middle ground for now.

5

Right! There can actually be releases that don’t restart VMs, so it’ll frequently change in a way that would put the environment variable out of sync.

We might be able to expose current version from an API, though, or even a DNS txt query. We can keep that updated at least!

4 Likes
6

I found a way to get the version from the GraphQL endpoint, via curl or JavaScript fetch

Okay so at least the in Deno version works :heart_eyes:
It’s actually just JavaScript

fetch("https://api.fly.io/graphql", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: "Bearer XXX", // Replace XXX with your Access Token
  },
  body: JSON.stringify({
    query: `
    query($appName: String!) {
      app(name: $appName) {
        currentRelease {
          version
          status
        }
      }
    }`,
    variables: {
      appName: "YOUR_APP_NAME",
    },
  }),
})
  .then((res) => res.json())
  .then((res) => console.log(res.data));

which results in:

{
  app: {
    currentRelease: {
      version: 49,
      status: "succeeded"
    }
  }
}

:partying_face:

Get your access token via:
Fly.io web dashboard, selecting Account :arrow_right:︎ Settings :arrow_right:︎ Access Tokens :arrow_right:︎ Create Access Token

The curl version

curl -X POST -H "Content-Type: application/json" \
-H "Authorization: Bearer FLY_API_TOKEN" \
--data '{"query":"query($appName:String!){app(name:$appName){currentRelease{version status}}}","variables":"{\"appName\":\"FLY_APP_NAME\"}"}' \
https://api.fly.io/graphql

which results in a string

{"data":{"app":{"currentRelease":{"version":55,"status":"succeeded"}}}}
1 Like
7

Is there any change on this?

It would be really useful to be able to get the build number or the git revision number. I know I can set an env var for GIT_REVISION myself through the CLI, but it would be great to not have to add this myself as my deploy command is already long enough. :wink:

1 Like
8

The flyctl info command now has VERSION.

So you can modify your Dockerfile and pass

--build-args BUILD_VERSION=$(flyctl info --app APP | grep 'Version' | tr -s ' ' | cut -d' ' -f4)

2 Likes
9

I’m also curious if there’s any movement on the ability to pass env vars in a first-class fashion.

Git commits are frequently used to tie exceptions and performance metrics to specific SHAs, and most PaaS’s support passing them as env vars from CI/CD pipelines.

1 Like