Support git version from environment

[bsheedy-work]

Adds support in version.ts for retrieving the version from the WEBGPU_CTS_GIT_VERSION environment variable instead of from calling "git describe" directly. This is so that the tests can be run in contexts where the actual git checkout is not available, such as in certain cases within Chromium.

Issue: #

---

Requirements for PR author:

• All missing test coverage is tracked with "TODO" or .unimplemented().
• New helpers are /** documented */ and new helper files are found in helper_index.txt.
• Test behaves as expected in a WebGPU implementation. (If not passing, explain above.)
• Test have be tested with compatibility mode validation enabled and behave as expected. (If not passing, explain above.)

Requirements for reviewer sign-off:

• Tests are properly located in the test tree.
• Test descriptions allow a reader to "read only the test plans and evaluate coverage completeness", and accurately reflect the test code.
• Tests provide complete coverage (including validation control cases). Missing coverage MUST be covered by TODOs.
• Helpers and types promote readability and maintainability.

When landing this PR, be sure to make any necessary issue status updates.

[kainino0x]

This is fine, though I think there are two other simpler possible solutions:

• Non-node builds replace this file with a generated file containing the hash.
  If we are building the project first (e.g. into out-node) then that would work (actually it would be more correct because it would tell you the commit hash of the built code).
  But IIRC you said we were not building the project first which means we're using something like tools/run_node? In which case we can't do that.
  IIRC you said we were not building the project first (into out-node) but using something like tools/run_node? If so then I don't think that would work
• I don't think the version actually needed though (it only happens if you try to serialize the test results as JSON) so we could try replacing version with version() so it's computed on demand.

[bsheedy-work]

But IIRC you said we were not building the project first which means we're using something like tools/run_node?

Correct.

I don't think the version actually needed though

Good point, I'll give that a try locally.

[bsheedy-work]

Actually, it seems like we do need the version. The relevant Dawn code that is hitting this is explicitly calling the gen_version tool. See the go tool and relevant gruntfile entry.

[kainino0x]

Oops, I thought this was reachable through Logger.asJSON. That was wrong though, that's a different file version.js.

Also didn't realize run-cts had its own build steps, that's annoying complexity. I am not sure why it even needs to run:generate-version. If it doesn't run that, it should just get "unknown" which seems fine (if it even calls Logger.asJSON at all which I doubt it does). We certainly don't need it on bots, they already know what DEPS version they have. I don't see why it would be needed in local development either. Could you try just removing that step?

[bsheedy-work]

No luck, it seems like npx grunt node still depends on version.ts:

failed to build cts node: exit status 1: Running "clean:gen" (clean) task
>> 0 paths cleaned.
�[0;35mTask 'clean:gen' took 10ms�[0m

Running "run:generate-version" (run) task
fatal: not a git repository (or any of the parent directories): .git
Error: Command failed: git describe --always --abbrev=0 --dirty
fatal: not a git repository (or any of the parent directories): .git

Seems like that's due to the node task running generate-common which runs clean:gen followed by run:generate-version.

[kainino0x]

Ah that makes sense, I thought building the CTS turned out not to be necessary but that was just in the GN files, Go is still invoking the compilation. (It looks like run-cts does not use tools/run_node, it just runs various other tools through ts-in-node.)

Let me see about just removing this from the dependency chain for npx grunt node since it's not used.

[kainino0x]

OK, that's kind of a pain. What about this? #4455

[bsheedy-work]

What about this?

Seems to work fine. I'm not able to test directly on the bots due to how the CTS repo gets DEPSed in, but I'm able to run the tests locally even when changing git to something that doesn't exist so that the command fails.

[bsheedy-work]

Abandoning this since Kai's pull request should resolve the problem this was trying to solve.