Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose Git commit hash in star.json and via Meteor.gitCommitHash. #10442

Merged

Conversation

Projects
None yet
7 participants
@benjamn
Copy link
Member

commented Feb 4, 2019

It's often useful for a running Meteor app and/or a hosting platform (like Galaxy) to know which version of the application is currently running. One easy way to provide that information (without any manual effort by the developer) is to expose the current Git revision. In Meteor terms, the most convenient places to put this information are in the star.json file included in the build directory (for consumption by deployment tools) and the Meteor.gitCommitHash property that's available on both the client and the server at runtime.

benjamn added some commits Feb 4, 2019

Add gitRevision property to star.json and __meteor_runtime_config__.
This information is useful when you need a unique identifier for the
current version of the application (and you're using Git).

If the current Git HEAD revision can't be found for any reason, the
gitRevision property simply will not appear in star.json or
__meteor_runtime_config__.

@benjamn benjamn added this to the Release 1.8.1 milestone Feb 4, 2019

@benjamn benjamn self-assigned this Feb 4, 2019

@jamesmillerburgess

This comment has been minimized.

Copy link
Contributor

commented Feb 4, 2019

Wow, great! Our team was asking about a feature like this recently!

@benjamn benjamn requested review from abernix and hwillson Feb 4, 2019

@benjamn benjamn force-pushed the add-gitRevision-to-star.json-and-runtime-config branch from 3926781 to ba5b81b Feb 4, 2019

@benjamn

This comment has been minimized.

Copy link
Member Author

commented Feb 4, 2019

If anyone is interested in supporting other version control tools like CVS or Monotone or Darcs or Microsoft Visual SourceSafe, feel free to submit a pull request! :trollface:

In all seriousness I am curious if there is any interest at all beyond Git. Subversion? Mercurial?

@abernix

abernix approved these changes Feb 4, 2019

Copy link
Member

left a comment

I'm not sure taking the time to generalize the property to be non-git-specific (e.g. scmRevision, vcsRevision, revision, etc.) is even worth bringing up, but here I am.
I felt like it was wrong not to at least mention it.

LGTM. (As is.)

Show resolved Hide resolved tools/fs/files.js Outdated

benjamn added some commits Feb 4, 2019

@benjamn benjamn force-pushed the add-gitRevision-to-star.json-and-runtime-config branch from ba5b81b to c4e6cdb Feb 4, 2019

@hwillson
Copy link
Member

left a comment

Looks great @benjamn - thanks!

@glasser
Copy link
Member

left a comment

This is really great. I look forward to implementing parsing of star.json for the Galaxy frontend.

Show resolved Hide resolved History.md Outdated
Show resolved Hide resolved packages/meteor/server_environment.js Outdated
Show resolved Hide resolved tools/fs/files.js Outdated
Show resolved Hide resolved tools/isobuild/bundler.js Outdated

benjamn added some commits Feb 4, 2019

@benjamn benjamn changed the title Add Git revision to star.json and __meteor_runtime_config__. Expose Git commit hash in star.json and via Meteor.gitCommitHash. Feb 4, 2019

@benjamn benjamn force-pushed the add-gitRevision-to-star.json-and-runtime-config branch from ba967d7 to ca59b22 Feb 4, 2019

Attempt to fix tests by reverting puppeteer from 1.12.1 to 1.6.2.
Tests have started failing for reasons that may be related to puppeteer's
Meteor process management: https://circleci.com/gh/meteor/meteor/31035

Since I can't identify any other possible causes, using the same version
of puppeteer that other tests use (e.g. modules, dynamic-import) seems
like a reasonable first step.

Also updated puppeteer in tests/apps/app-config/package-lock.json to
version 1.6.2 (was 1.3.0), in an attempt to fix some unhandled promise
rejection warnings: https://circleci.com/gh/meteor/meteor/31063

@benjamn benjamn force-pushed the add-gitRevision-to-star.json-and-runtime-config branch from ca59b22 to 0f48028 Feb 4, 2019

@benjamn benjamn merged commit 808d78d into release-1.8.1 Feb 4, 2019

19 checks passed

CLA Author has signed the Meteor CLA.
Details
ci/circleci: Clean Up Your tests passed on CircleCI!
Details
ci/circleci: Docs Your tests passed on CircleCI!
Details
ci/circleci: Get Ready Your tests passed on CircleCI!
Details
ci/circleci: Isolated Tests Your tests passed on CircleCI!
Details
ci/circleci: Test Group 0 Your tests passed on CircleCI!
Details
ci/circleci: Test Group 1 Your tests passed on CircleCI!
Details
ci/circleci: Test Group 10 Your tests passed on CircleCI!
Details
ci/circleci: Test Group 2 Your tests passed on CircleCI!
Details
ci/circleci: Test Group 3 Your tests passed on CircleCI!
Details
ci/circleci: Test Group 4 Your tests passed on CircleCI!
Details
ci/circleci: Test Group 5 Your tests passed on CircleCI!
Details
ci/circleci: Test Group 6 Your tests passed on CircleCI!
Details
ci/circleci: Test Group 7 Your tests passed on CircleCI!
Details
ci/circleci: Test Group 8 Your tests passed on CircleCI!
Details
ci/circleci: Test Group 9 Your tests passed on CircleCI!
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@benjamn benjamn deleted the add-gitRevision-to-star.json-and-runtime-config branch Feb 4, 2019

@benjamn

This comment has been minimized.

Copy link
Member Author

commented Feb 5, 2019

Small note: the commit hash is only updated when writeSiteArchive is called, which only happens when we rebuild the server bundle, so it won't be updated (for example) when the build system does a client-only refresh. We also don't attempt to watch any files within the .git directory, so creating a new Git commit on the command line is not by itself going to trigger a Meteor rebuild, unless application files are changed in the process. In other words, the commit hash is completely trustworthy when you first start the server or do a build/deploy, but it might lag behind while you're developing the app. I don't think this should be a problem in practice, but wanted to make a note of it anyway.

@aliogaili

This comment has been minimized.

Copy link

commented Feb 6, 2019

This great, we were trying to implement something like that! thank you Benjamn!!

@Floriferous

This comment has been minimized.

Copy link

commented Apr 3, 2019

We were using a small setup script before deploying that would write the commit hash to a file called commit.txt and put it inside the public folder, we can now stop doing that :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.