Make the git SHA of the currently deployed code visible through ember-cli-app-version

[carols10cents]

I had this at a previous job and it was incredibly useful-- anyone could help debug a problem with the additional information of knowing whether the current master branch matches what's on production.

As discussed below, the frontend part is blocked waiting on this PR to ember-cli-app-version.

The backend way to get this info isn't blocked though, and implementing that will entail:

• Add a new get route to the api_router around here in src/lib.rs that's something like /deployed_sha (I wouldn't call it anything like "version" since we have crate versions all over the place and this isn't a crate version)
• Make that route call a new function, which could probably just live in src/lib.rs since it'll be small and doesn't really have anything to do with anything else, or mayyybe in src/util/ somewhere, up to you.
• Make that function return JSON that looks something like {"sha": "259d028bd03a07b2560f873add4b45f35b1d565b"}. Assume that I've enabled this heroku labs feature and that the sha is available in the env var HEROKU_SLUG_COMMIT. This code is a decent example of constructing a JSON response that has a String value
• If HEROKU_SLUG_COMMIT isn't set, this function shouldn't panic, have it return {"sha": "unknown"} or something. This code is a decent example of getting an env var and using a default value if the env var isn't set.
• Locally, run HEROKU_SLUG_COMMIT=something cargo run --bin server and then visit http://localhost:4200/api/v1/deployed_sha (or whatever you decided to call the route), and verify that you get the JSON you expect with the value you set the env var to.
• Also run without that env var, visit the same url, and verify you get the default value.

I'm not even sure how you'd write automated tests for this backend route, so I don't think figuring that out is worth it. Manual verification should be fine.

[locks]

@carols10cents have you seen ember-cli-app-version?

[carols10cents]

I HAVE NOT BUT THAT'S WHAT I WANT!!!!!!!!!!!

[jtgeibel]

I'd be interested in helping with the backend implementation. I think we would have to capture the git sha during the build.

It looks like https://github.com/rustyhorde/vergen would be an option. It also looks like the next stable release (this week already?) will allow for setting environment variables from the build script. rust-lang/cargo#3929 (comment)

[carols10cents]

@jtgeibel do you think we need a backend implementation? The backend and frontend should be running the same SHA, right? Or do you mean we should have an API route that returns the SHA so that you don't have to ask the frontend for this information necessarily?

[jtgeibel]

The backend and frontend should be running the same SHA, right?

@carols10cents that's a really interesting question that I hadn't thought about. In production they should never diverge, but during development they would when using npm run start:live or npm run start:staging.

I'm new to ember and originally misunderstood how ember-cli-app-version works. I've looked at it closer and I now believe it gets the SHA during the build and then stores this in a meta tag with other ember config information.

A backed API may be slightly nicer because during development you already know what is in the working directory and it would be nice to see the SHA for the backend version. However, overall I'm pretty neutral on the implementation.

[carols10cents]

but during development they would when using npm run start:live or npm run start:staging.

OOOOHH hhhmmmmm!! good point!

A backend API may be slightly nicer because during development you already know what is in the working directory and it would be nice to see the SHA for the backend version.

Orrrr if you're not running the frontend at all! I don't know if there are any deployments like this out there, but theoretically you could just run the backend and only interact with the API, in which case a backend API to get this would be nice.

However, overall I'm pretty neutral on the implementation.

I think I would merge PRs for either or both :)

[jtgeibel]

So it looks like we're already using ember-cli-app-verison. Now that I have the front-end up and running locally I see the version reported as 0.0.0+ccadd334. However, on production there is no git hash, it is only 0.0.0+.

It seems the git repository is not available at build time on heroku. Instead a SOURCE_VERSION environment variable is provided to the build. There is a pull request upstream at ember-cli/ember-cli-app-version#42, which is awaiting review.

[notriddle]

Heroku does provide access to the git hash at runtime. You just have to turn it on.

[treiff]

Planning on giving this a shot, if anyone is already on it let me know and I'll track down something else.