Java Test Runner

Java Test Runner

Integration-test environment and diagnostics

These details concern the integration-test harness in microsoft/vscode-java-test, not settings imposed on users' test projects.

• Dedicated VS Code user data: test/index.ts::main creates .vscode-test/user-data/User under the repository and writes settings.json before its two runTests calls. Both the Maven/JUnit workspace suite and unmanaged-folder suite receive the same directory through --user-data-dir; this is a shared test profile, not a fresh profile per suite. [1]
• AI features disabled for test launches: that settings file sets chat.disableAIFeatures to true. Both launches also pass --disable-extension for GitHub.copilot-chat and TypeScriptTeam.jsts-chat-features. [1]
• Explicit language-server Java selection: when JAVA_HOME is nonempty, the generated settings include java.jdt.ls.java.home with that value. The Linux, Windows, and macOS CI jobs install Temurin JDK 25 (replacing 21). This records the CI runtime choice, not a minimum Java target for users' projects. [1][2]
• Failure-log location: all three CI jobs collect JDT language-server logs from .vscode-test/user-data/User/workspaceStorage/*/redhat.java/jdt_ws/.metadata/.log on failure, rather than the normal OS-specific VS Code user-data location. Use the test-profile path when investigating these integration runs. [2]

Evidence and scope

Verified against merged source commit 7e2584d2d44804999c3d06a2605e9352782d7e6b in PR #1937. Both changed files were inspected; their main file blobs matched the merged revision at maintenance time. This documents harness configuration, not a verified successful CI run or a release/deployment claim.

1. test/index.ts, main and both runTests calls.
2. .github/workflows/build.yml, linux, windows, and darwin jobs.

Repository team-memory workflow and manual recovery

The following caller configuration is verified at 84fa601956f106db9c63c753c11a48acdaca91d5, the merge of microsoft/vscode-java-test PR #1936. Both changed files were inspected at that revision, also the supplied push-after and source-tip revision. This is repository automation, not Java test execution behavior.

• Triggers and opt-in: Update IssueLens Team Memory now listens to pushes to main, replacing pull_request_target: closed. Manual recovery remains available through workflow_dispatch with a required string pull_request_number. For either event, the job requires ISSUELENS_TEAM_MEMORY_ENABLED == 'true' and a ref matching the repository's current default branch. The push branch filter is explicitly main; changing the default branch alone does not change that filter. [3]
• Concurrency: the group includes the source repository and github.event.after for pushes, falling back to the manual PR number and then run ID. cancel-in-progress remains false. This is not a cross-repository lock on the shared wiki; maintenance still needs destination and snapshot conflict checks. [3][4]
• Execution boundary: the job timeout is 30 minutes. Its sole step invokes microsoft/IssueLens/.github/actions/issuelens@2b5317815e15179899014a02c41678620ce2d390 with request-type: team-memory; there is no consumer checkout step. The caller retains contents: read, pull-requests: read, and id-token: write, with output-mode: activity and summary-mode: status. These source checks do not verify Azure federation, external action internals, or live workflow success. [3]

3. .github/workflows/team-memory-post-merge.yml, triggers, concurrency, and jobs.team-memory.
4. .github/issuelens/team-memory.md, Maintenance and provenance.