Skip to content
This repository has been archived by the owner on Nov 27, 2018. It is now read-only.

include git revision/tag in template app #9

Open
mykmelez opened this issue Sep 22, 2015 · 4 comments
Open

include git revision/tag in template app #9

mykmelez opened this issue Sep 22, 2015 · 4 comments
Assignees

Comments

@mykmelez
Copy link
Contributor

Building the template app should interject the Git revision ID (and tag, if the current revision is tagged) into the app somewhere subtle but visible for those who know where to look for it.

Then it'll be easier to see when the template app (and any app based on the template that doesn't remove the feature) has been updated in GitHub Pages, which could be useful when debugging the update flow (#5), especially since there's a delay of up to ten minutes (although it's usually less than a minute) between when you deploy an app and when it shows up on GitHub Pages.

Since the template app has a package.json file, and npm version updates the version in the file (while also tagging the current revision, per https://docs.npmjs.com/getting-started/publishing-npm-packages#updating-the-package), gulpfile.js could use var packageJson = require('./package.json'); to get the version number from the package for folks who are using npm version to version their apps, although that requires a manual step, and it'd be better to do this automagically.

Of note:

git rev-parse HEAD: the current revision ID
git describe --abbrev=0 --tags: the tag on the branch
git describe --abbrev=0 --tags --exact-match: the most recent tag on the current revision

(If we wanted to get fancy, we could distinguish between deployment of a clean working directory, where git status shows no changes, and deployment of a dirty one, where git status shows that there are changes that have not been committed yet.)

@mykmelez mykmelez modified the milestone: v1 Oct 7, 2015
@brendandahl
Copy link
Contributor

Was this based on the old flow of cloning the repo?

It seems we should just take the npm version of oghliner and put that into the index.html file during oghliner bootstrap.

@mykmelez
Copy link
Contributor Author

Was this based on the old flow of cloning the repo?

This is actually to determine the deployed version of an app based on the template, not to determine the version of the template that was used to create the app.

@wfwalker asked for this when he was debugging an app update whose differences from the previous version of the app were subtle. He wanted to ensure that the app his browser was loading was the new version rather than the old one.

Since the "version" in this case is just the particular Git revision that he deployed, writing the revision ID into the index.html file before deploying it would enable him to figure out what version of the app he's looking at by checking that value in the HTML file.

(Including the version of Oghliner that was used to bootstrap the app would also be useful, as would a reference and link to Oghliner.)

@brendandahl brendandahl self-assigned this Oct 14, 2015
@brendandahl
Copy link
Contributor

@mykmelez Do we still want to do this after @wfwalker's comment of "I think I mostly want to have programmatic knowledge of whether this instance of the app is up to date"?

I think the current issue description could still be a nice feature, but it does make us bring in templating to the template app build step.

@mykmelez mykmelez removed this from the v1 milestone Nov 2, 2015
@mykmelez
Copy link
Contributor Author

mykmelez commented Nov 2, 2015

I think the current issue description could still be a nice feature, but it does make us bring in templating to the template app build step.

Hmm, indeed. I agree, it'd be a nice feature to have (even if it isn't the feature that @wfwalker actually wants!). And I'm ok with adding templating to the template app build step (even though it reminds me of Inception!). But it doesn't need to happen for v1.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants