Git commit sha of current build

1

Is it possible to get the git commit sha for the build that’s running? I like to use it to display the latest commit information for my discord bot.

image
image1206×628 67.9 KB

On Heroku, I had an environment variable for this: SOURCE_VERSION.

2

Since the image is built with flyctl it would need to save the git sha or whatever else you want to the image. You can do it with something like this:

flyctl deploy —build-arg COMMIT=$(git rev-parse HEAD)

Then in your image, add

ARG COMMIT
ENV COMMIT=$COMMIT
2 Likes
3

That makes sense. How would I do it if I don’t have a docker image? I’m using regular node.js.

4

I assume that you’re using the “Node.js builtin”? You can confirm by seeing if you have the following defined in your fly.toml:

[build]
  builtin = "node"

As far as I understand, the default Node.js builtin provided by flyctl is just spinning up the node:current-slim Docker image under the hood, with some shuffling of files around. Unfortunately as the stock standard images don’t have any predefined ARG values, there’s no way to pass any values through short of having your own Dockerfile.

Now having said that, flyctl does also have support for buildpacks which is one way you might solve what you’re after.

In short, it shouldn’t be much more than changing your build step to look like so:

[build]
  builder = "gcr.io/paketo-buildpacks/builder:base"

With that, you can pass in arbitrary inputs with the BPE_ prefix so for example, flyctl deploy --build-arg BPE_COMMIT_SHA=abc123 will make the provided value available to your application via process.env.COMMIT_SHA.

You may want to read the buildpack documentation. I’m not hugely familiar with it but I deployed a quick test just now to confirm that you can pass through environment variables. I think the short version is that it’ll just run whatever you’ve provided as your start script ie; whatever runs as a result of npm/yarn start.

On a side note, it’s probably worth asking the fly team if they think it makes sense to prepopulate the stock Node.js image with a couple of commonly used ARGs such as COMMIT_SHA but I suppose at that point, it’s just as easy for users to switch to buildpacks.

1 Like
5

You can also simply supply env vars at deploy time. The caveat here is that if you have any uncommitted changes at deploy time, this value won’t be correct. Might be OK for a CI pipeline though.

fly deploy -e COMMIT=$(git rev-parse HEAD)
2 Likes
6

If I have to go through all that trouble I probably should just use Docker :sweat_smile: Thanks for the thorough answer though!

7

That sounds nice and easy. Would that be accessible to the running application? Or would it just be accessible during build time?

8

Ahhh, yes yes, @jsierles is correct. Apologies, I’m still thinking in terms of running containers on the other end which isn’t what fly are doing here of course :wink:

Yep, as mentioned, running eg -e BLAH=VALUE is all you need it seems then you can just reference it at process.env.BLAH within your application.

That’s definitely much nicer.

1 Like
9

fly deploy -e will be available at runtime.

Using a build arg would be better if you want the actual resulting Docker image to contain an immutable reference to the build it contains. That would be useful, for example, if you were to reuse the image locally or in a staging environment.

2 Likes