Add test runner option --log-test-environment #25843

juj · 2025-11-20T22:29:25Z

Add test runner option --log-test-environment, which will introspect and print detailed information about Emscripten tool setup: Emcc, Clang, Binaryen, Node, Python and LLVM. This helps CI maintainers emit info to test run logs of the active setup for reference.

test/runner --log-test-environment <tests_to_run> will then print a following log info dump before starting the tests:


C:\emsdk\emscripten\main>test\runner --log-test-environment
======================== Test Setup ========================
Test time: Thursday, November 20, 2025 22:28:18 UTC
Python: "C:\emsdk\python\3.13.3_64bit\python.exe". Version: 3.13.3 (tags/v3.13.3:6280bb5, Apr  8 2025, 14:47:33) [MSC v.1943 64 bit (AMD64)]
Emscripten test runner path: "C:\emsdk\emscripten\main\test\runner.py"

Emscripten repository: "C:\emsdk\emscripten\main"
emscripten-version.txt: 4.0.21-git

Emscripten commit cce3a701889bbc5b107056b0de3fab8d5ce6f885
Author: Jukka Jylänki <jujjyl@gmail.com>
Date:   Fri Nov 21 00:26:51 2025 +0200

    Add test runner option --log-test-environment, which will introspect and print detailed information about Emscripten tool setup: Emcc, Clang, Binaryen, Node, Python and LLVM. This helps CI maintainers emit info to test run logs of the active setup for reference.

EM_CONFIG: "C:\emsdk\.emscripten"

import os
emsdk_path = os.path.dirname(os.getenv('EM_CONFIG')).replace('\\', '/')
LLVM_ROOT = emsdk_path + '/llvm/git/build_main_vs2022_64/Release/bin'
NODE_JS = emsdk_path + '/node/22.16.0_64bit/bin/node.exe'
EMSDK_CMAKE = emsdk_path + '/cmake/4.2.0-rc3_64bit/bin/cmake.exe'
PYTHON = emsdk_path + '/python/3.13.3_64bit/python.exe'
EMSCRIPTEN_ROOT = emsdk_path + '/emscripten/main'
BINARYEN_ROOT = emsdk_path + '/binaryen/main_vs2022_64bit_binaryen'
MINGW_ROOT = emsdk_path + '/mingw/7.1.0_64bit'
NINJA = emsdk_path + '/ninja/git-release_64bit/bin'
EMSDK_ACTIVATED_TEST_BROWSER = emsdk_path + '/firefox/78.15.0esr_64bit/firefox.exe'

NODE_JS: ['C:/emsdk/node/22.16.0_64bit/bin/node.exe']. Version: v22.16.0
BINARYEN_ROOT: C:/emsdk/binaryen/main_vs2022_64bit_binaryen
wasm-opt version: wasm-opt version 124 (version_124-122-g8a66d2a7d)
Binaryen git directory: "C:\emsdk\binaryen\main"

Binaryen commit 8a66d2a7d48a0014dce5e22a2fa8eee12eb09b7c
Author: Alon Zakai <azakai@google.com>
Date:   Thu Nov 6 11:53:49 2025 -0800

    GUFA: Represent imported functions as globals (#8025)

    The meaning of Global in PossibleContents changes from "an actual wasm
    Global" to "an immutable global wasm thing, either a Global or a Function."
    Imported wasm Functions are effectively immutable values in the global
    scope - not concrete, specifically-known functions - so this is more correct.

    In particular, two imported Globals (of compatible types) might or might not
    be the same, and likewise with imported Functions. And that is not the case
    for defined Functions - they are definitely different.

    This does not fix the issues related to imported function type handling -
    #7993 does that - but this refactoring makes it possible to properly
    optimize imported functions afterward.

    This does make the PossibleContents object grow from 32 to 40 bytes,
    which might be why this adds 3-4% overhead to GUFA, but I don't see a
    good way to avoid that, unfortunately. Keeping our ability to optimize
    imported functions might be worth that 3-4% (we recently saw a few digits
    improvement due to properly optimizing imported externs, for example,
    from #8005).

LLVM_ROOT: C:/emsdk/llvm/git/build_main_vs2022_64/Release/bin
LLVM git directory: "C:/emsdk/llvm/git\src"

LLVM commit d65be16ab6adf00af21e75d29049ae5de0f3a38a
Author: Ryan Cowan <ryan.cowan@arm.com>
Date:   Mon Nov 17 15:55:40 2025 +0000

    [AArch64][GlobalISel] Add combine for build_vector(unmerge, unmerge, undef, undef) (#165539)

    This PR adds a new combine to the `post-legalizer-combiner` pass. The
    new combine checks for vectors being unmerged and subsequently padded
    with `G_IMPLICIT_DEF` values by building a new vector. If such a case is
    found, the vector being unmerged is instead just concatenated with a
    `G_IMPLICIT_DEF` that is as wide as the vector being unmerged.

    This removes unnecessary `mov` instructions in a few places.

Clang: "C:/emsdk/llvm/git/build_main_vs2022_64/Release/bin\clang.exe"
clang version 22.0.0git (https://github.com/llvm/llvm-project.git d65be16ab6adf00af21e75d29049ae5de0f3a38a)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\emsdk\llvm\git\build_main_vs2022_64\Release\bin

EMTEST_BROWSER: "C:\\emsdk\\firefox\\78.15.0esr_64bit\\firefox.exe" -new-instance -wait-for-browser
Firefox version: 78
Not detected as a Safari browser

EMSDK: "C:/emsdk"

Emsdk commit fe91d96cfd53f505a2ce561b01320124bff438a1
Author: Jukka Jylänki <jujjyl@gmail.com>
Date:   Mon Nov 17 18:41:28 2025 +0200

    Use exit_with_error

==================== End of Test Setup =====================

…and print detailed information about Emscripten tool setup: Emcc, Clang, Binaryen, Node, Python and LLVM. This helps CI maintainers emit info to test run logs of the active setup for reference.

sbc100

Seems like useful thing!

test/runner.py

sbc100 · 2025-11-20T23:34:42Z

test/runner.py

+    print(f'\n{utils.read_file(config.EM_CONFIG).strip()}\n')
+
+  node_js_version = subprocess.run(config.NODE_JS + ['--version'], stdout=subprocess.PIPE, text=True).stdout.strip()
+  print(f'NODE_JS: {config.NODE_JS}. Version: {node_js_version}')


We already have this available via utils.get_node_version()

There's shared.get_node_version(), but that parses the output. I think it's better in this case to output the raw version string as emitted by NODE_JS --version.

test/runner.py

sbc100 · 2025-11-20T23:37:22Z

test/runner.py

+    print_repository_info(llvm_git_root, 'LLVM')
+
+  clang_version = subprocess.run([shared.CLANG_CC, '--version'], stdout=subprocess.PIPE, text=True).stdout.strip()
+  print(f'Clang: "{shared.CLANG_CC}"\n{clang_version}\n')


We have shared.get_clang_version() for this.

That too parses the output - it would be preferable to print the raw output here.

test/runner.py

sbc100 · 2025-11-20T23:43:45Z

test/runner.py

+  import subprocess
+  current_commit = subprocess.run(['git', 'log', '-n1'], cwd=directory, stdout=subprocess.PIPE, text=True).stdout.strip()
+  print(f'\n{repository_name} {current_commit}\n')
+  local_changes = subprocess.run(['git', 'diff'], cwd=directory, stdout=subprocess.PIPE, text=True).stdout.strip()


Maybe just remove the stdout=subprocess.PIPE so that the output goes directly to stdout?

This doesn't work for Windows at least, but enters an interactive git diff prompt.

test/runner.py

sbc100 · 2025-11-21T17:16:23Z

test/runner.py


  browser_common.init(options.force_browser_process_termination)

+  if options.log_test_environment:


I guess we should probably print all this into in circle CI too. The best way to do that is probably to add or os.getenv('CI').

Sounds good. Added os.getenv('CI').

sbc100 · 2025-11-21T21:04:44Z

Do we really need show the whole commit messsage from at HEAD for each repo?

Isn't the revision enough? The commit message seems to add a log noise to me.

juj · 2025-11-21T21:14:28Z

I thought it would be a good way to read out what the current tested commit was.

When I see a list of

<red>
<red>
<green>
<green>
<green>

test runs on my CI (runs in newest to oldest order), I could look at the first red run, and then read the commit message there - that would give a direct PR #number to find what regressed.

If I only printed a commit hash, I would then need to go and git log it manually. Of course doable, but I figured why not just provide the information automatically - that way the test logs would carry more information without having to translate manually.

sbc100 · 2025-11-21T21:18:38Z

I thought it would be a good way to read out what the current tested commit was.

When I see a list of
<red>
<red>
<green>
<green>
<green>
test runs on my CI (runs in newest to oldest order), I could look at the first red run, and then read the commit message there - that would give a direct PR #number to find what regressed.

If I only printed a commit hash, I would then need to go and git log it manually. Of course doable, but I figured why not just provide the information automatically - that way the test logs would carry more information without having to translate manually.

I think the commit has is normally enough for me, but maybe can do git log --abbrev-commit -n1 --pretty=oneline as a compromise?

juj · 2025-11-21T21:21:51Z

Ok, that works.

juj added 3 commits November 21, 2025 00:28

Add test runner option --log-test-environment, which will introspect …

cce3a70

…and print detailed information about Emscripten tool setup: Emcc, Clang, Binaryen, Node, Python and LLVM. This helps CI maintainers emit info to test run logs of the active setup for reference.

ruff

c6fdc54

ruffer

ec96ead

sbc100 reviewed Nov 20, 2025

View reviewed changes

review

fc9533f

sbc100 reviewed Nov 21, 2025

View reviewed changes

juj added 2 commits November 21, 2025 22:13

review

a9a6fff

ruff

0352e79

short git log

54ae64c

sbc100 approved these changes Nov 21, 2025

View reviewed changes

juj merged commit 343fed5 into emscripten-core:main Nov 21, 2025
34 checks passed


		browser_common.init(options.force_browser_process_termination)

		if options.log_test_environment:

Add test runner option --log-test-environment #25843

Add test runner option --log-test-environment #25843

Conversation

juj commented Nov 20, 2025

Uh oh!

sbc100 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sbc100 commented Nov 21, 2025

Uh oh!

juj commented Nov 21, 2025

Uh oh!

sbc100 commented Nov 21, 2025

Uh oh!

juj commented Nov 21, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants