Chakracore: ch.exe needs --version

[bterlson]

At a minimum it could simply pull the current commit's metadata and report commit hash and commit date.

[tcare]

I believe we already store this sort of data in the DLL - it shouldn't be too hard to get it out. @curtisman and @digitalinfinity know the details of the encoding.

[dilijev]

@curtisman recently made a change in this area. https://github.com/Microsoft/ChakraCore/commit/0813dc1d3847478e420842dbf6ee9015ad1ce4c6

See: https://github.com/Microsoft/ChakraCore/blob/master/lib/common/CommonDefines.h

I think it would be reasonable for ch.exe to report the same version as ChakraCore.dll

[ianwjhalliday]

This should be better defined. After a quick discussion with @curtisman the version should at least be the major and minor numbers and build flavor and whether it is prerelease or not.

I believe all this information can be read from the resource file in chakracore.dll so ch.exe need not directly reference macros to get this information.

The FileDescription and FileVersion resource fields include all the above mentioned pieces of version/build information. Timestamp is also available.

As for getting the commit information that would require embedding that information during build time. More work to get that going.

[curtisman]

There is actually an mechanism to embed commit hash in the version description in the resources already; by defining CHAKRA_VERSION_BUILD_COMMIT in the environment. Our internal build system defines it for us, but in order to get it automatically, the msbuild project needs to be update to get it from the git repo.

Note that the commit hash is still not 100% accurate, as it may be built with uncommitted changes.

[digitalinfinity]

Brian, what exactly is the use case here? Is it for internal build system binaries or ones built locally?

-Hitesh.

On Jan 15, 2016, at 10:16, Curtis Man <[email protected][e-mail]> wrote:

There is actually an mechanism to embed commit hash in the version description in the resources already; by defining CHAKRA_VERSION_BUILD_COMMIT in the environment. Our internal build system defines it for us, but in order to get it automatically, the msbuild project needs to be update to get it from the git repo.

Note that the commit hash is still not 100% accurate, as it may be built with uncommitted changes.

Reply to this email directly or view it on GitHubhttps://github.com/Microsoft/ChakraCore/issues/109#issuecomment-171871227.

[bterlson]

Sorry @digitalinfinity missed your comment. The use case is knowing what version a .exe comes from, whether built locally at some point or pulled from a build server. A specific use case is for https://github.com/bterlson/eshost - I want to report a version hash next to the host name in the output.

[bterlson]

FWIW, commit hash would also make it easier to know which branch a build was produced from.

[ianwjhalliday]

@bterlson what does the --version output look like from the other engine console hosts?

+1 for commit hash. Brian and I were trying to determine if his build contained a particular commit and it would have been very quick if we could just --version to get the hash and compare with the commit in question.

[bterlson]

Node, V8, and jsshell gives a version number. None of them seem to include a commit hash.

[dilijev]

I think version number would be very helpful for debugging and triage. I'm not sure if being alike is the best answer in this case. +:one: for commit hash

[bterlson]

If we're pulling commit hash, we could also pull branch name and commit data as well! Something like:

<script engine major>.<script engine minor> <branch>@<short commit hash> (<commit-date>)

eg:

1.2 master@139fa91 (2016-20-01)

Would be so awesome!

[dilijev]

I don't remember where it was asked, but there was a question somewhere about how people would know if their changes had made it into a flight. Should we make this version string available in a release build in such a way that someone could check Chakra.dll to see what version of ChakraCore was included?

[bterlson]

That would of course be very handy, but may open other concerns (like, do you reflect security fixes in the version string?)

[obastemur]

<script engine major>.<script engine minor> <branch>@<short commit hash> (<commit-date>)

@bterlson @dilijev What if someone compiles CC from source code distro? How about starting with a basic version support and then if we want to include everything else, improve it?

Besides, we have separate Github branches per each release.

[dilijev]

At the moment we could easily expose <major>.<minor>.<patch> since they're encoded directly in the source already.

As for branch, commit hash, and commit date, the build would have to extract that information from Git metadata at build time. We already do this to some extent for our official builds because you'll see a string like this:

File version: 1.4.1.0 (release/1.4:3e2e2f353d71d8e3e8522fa04b9789cf1b5c35ac.00010.42060.170130-1858)

Which encodes:

<major>.<minor>.<patch>.0 (<branch>:<commit>.<buildnum-part1>.<buildnum-part2>.<build-date>)

See:
https://github.com/Microsoft/ChakraCore/blob/master/lib/Common/ChakraCoreVersion.h
https://github.com/Microsoft/ChakraCore/blob/master/bin/CoreCommon.ver

The Git metadata and build number information is exposed to the build by a file generated in the official build (which could be generated for general builds as well with a little bit of effort), Chakra.Generated.BuildInfo.props -- see note here

I think we could expose all of that information from ch.exe and display it when passed -v. We could even expose it as part of an object exposed to JavaScript so that someone could query the version at runtime, similar to how python exposes it's version at runtime. Not sure if there's a practical application for this though.

Keep in mind this information would be specific to binaries built with ChakraCore's build automation and against this repo, which means things like Node-ChakraCore would have a different story. If we're talking about specifically (and only) ch.exe then I don't think there's a problem.

[dilijev]

Example of the Chakra.Generated.BuildInfo.props file that is generated in pre_build.ps1 and consumed by the build:

<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <OutBaseDir>E:\d\ChakraCore\Build\VcBuild</OutBaseDir>
    <IntBaseDir>E:\d\ChakraCore\Build\VcBuild\obj\x86_release</IntBaseDir>
    <ChakraVersionBuildNumber>10</ChakraVersionBuildNumber>
    <ChakraVersionBuildQFENumber>42125</ChakraVersionBuildQFENumber>
    <ChakraVersionBuildCommit>release/1.4:7b859d11be25476d6dfb73d9306b6bc049b7c397</ChakraVersionBuildCommit>
    <ChakraVersionBuildDate>170130-2023</ChakraVersionBuildDate>
  </PropertyGroup>
</Project>

[dilijev]

If any of that data is not available, we would need to make sure we just fall back on the <major>.<minor>.<patch> info, like we do for binaries built locally by devs (which don't have an instance of that file to consume), for instance, a recent ChakraCore binary I built locally from master just has this: File version: 2.0.0.0 (instead of the whole string with all the info like above).

It would probably be a good idea to also mark the file as debug or something, but that information is also controlled by the flags in https://github.com/Microsoft/ChakraCore/blob/master/lib/Common/ChakraCoreVersion.h when figuring out whether to include that information in the binary metadata.

It might make the most sense to use the pre_build.ps1 and other build steps in a local build so that the commit hash and so on is available at build time (but that workflow needs a bit more work). And of course, it must still produce something valid if built in VS or simply by an msbuild invocation. So we need to have all the fallbacks when there is no info.

If a dev builds a binary and only gets the <major>.<minor>.<patch> info from -v, that dev will already know that they are testing a locally-built binary.

And of course, the Microsoft-signature will be the final indication about whether a binary was built by a dev or was an official release or preview release binary.

[dilijev]

I guess the question is: is <major>.<minor>.<patch> enough for the scenarios where people are asking (@bterlson @mathiasbynens), or is the other metadata significant enough that we should put more thought into it at this time? Making the -v with only the <major>.<minor>.<patch> info is trivial and foolproof as it's data that is definitely available at compile time no matter what.

[mathiasbynens]

Keep in mind this information would be specific to binaries built with ChakraCore's build automation and against this repo, which means things like Node-ChakraCore would have a different story. If we're talking about specifically (and only) ch.exe then I don't think there's a problem.

I was only talking about ch, indeed.

I guess the question is: is <major>.<minor>.<patch> enough […]

The <major>.<minor>.<patch> info would be significantly more useful than the current output, which is nothing at all. :) For the use case of https://github.com/mathiasbynens/homebrew-ecmascript (which would only host official releases) it would be sufficient.

Being able to differentiate between a dev build and an official release would be useful too, though it shouldn’t block the above.

[ThomsonTan]

To differentiate dev/private builds and help track the origin, I think it would also be useful if we add the build machine name to the version string (just expand some machine environment name in msbuild project file).

[bterlson]

@dilijev major minor patch is better than nothing but doesn't help differentiate intermediate builds which was the motivation for opening this in the first place.

[dilijev]

@bterlson - Fair enough. It seems like we should add major minor patch ASAP, and continue to think about the best way to provide additional information.

At present, it seems like it's easier to provide more information from official builds, and not so easy to provide that from dev builds, but the dev builds are the ones for which it is more important to have more information.

[dilijev]

I wasn't sure whether to include additional text (like ChakraCore v#.#.#) or just the <major>.<minor>.<patch> so I went with the simplest option for now, just #.#.#.

This also brings up another point. If this output is to be consumed by a tool which expects a short-ish version number, wouldn't we want to keep the output as minimally verbose as possible? All of the information we're talking about adding (commit, build number, machine name, prefix indicating a dev build, etc.), will make the output of this command quite long.

Perhaps we could have the essential information on line 1 and then provide additional information on subsequent lines of output.

[dilijev]

Copying some discussion from #2490 which seems broader than the PR and applies more to this general issue:

@liminzhu commented:

This sounds pretty useful. Is there a way for any embedder (not just ch) to programmatically know ChakraCore version #?

@jianchun commented:
>

This sounds pretty useful. Is there a way for any embedder (not just ch) to programmatically know ChakraCore version #?

We intend to ship "ChakraCoreVersion.h" file, and embedder knows it by including that header.

@dilijev commented:

@jianchun @liminzhu re: shipping ChakraCoreVersion.h -- the NuGet packages do not include this file since it's so minor. Would it be worth including it? Even so, that only solves the problem for Native projects.

For .NET projects which might want to report the ChakraCore version without hardcoding it, is there any kind of solution that would work that doesn't involve exposing a new API that reports the version info? Should we consider implementing such an API for the benefit of hosting? Is there some other approach that could work?

[dilijev]

@liminzhu Also, see the implementation I just added to the PR which reads the version of ChakraCore.dll directly from the binary. That's probably the best way for anyone to know (ch as well as any other hosts defined by implementers).

[liminzhu]

It looks like a good sample until we have the ChakraCoreVersion.h.

[dilijev]

@bterlson @mathiasbynens #2490 Has landed in release/1.4 for v1.4.1.

Output on Windows:

$ ch -v
ch.exe version 1.4.1.0
chakracore.dll version 1.4.1.0

Output on Linux:

~/dev/ChakraCore$ ./BuildLinux/Release/ch -v
ch version 1.4.1.0

Opened https://github.com/Microsoft/ChakraCore/issues/2505 for follow-up items. Closing this issue.