Four test cases under describe('js-executor'):
- sandbox isolates args from host realm (JVN#16937365 — regression guard)
- sandbox passes string args through unchanged
- non-sandbox path does not isolate from host realm (documented contract)
- non-sandbox path passes string args through unchanged
Tests use Node's built-in node:test + node:assert (zero new devDependencies;
ts-node was already there). Two npm scripts:
test — spec output for local dev
test:ci — spec to stdout + Node's built-in junit reporter to
target/surefire-reports/TEST-js-executor.xml
Wired 'yarn test:ci' into the Maven 'test' phase via frontend-maven-plugin,
so 'mvn test -pl=msa/js-executor' produces JUnit XML that TeamCity's
Maven runner auto-discovers under the 'js-executor' suite name.
TEST_FAST.md picks up the same step.
tsconfig excludes test/ from the production pkg bundle.
Under `mvn -T<n>` with the three yarn-using modules (ui-ngx,
msa/web-ui, msa/js-executor), concurrent yarn 1.x processes contend
on the shared `~/.cache/yarn`. The `--mutex network` flag was applied
only to `yarn install`, so `yarn run pkg` could overlap with another
module's install. Intermittent failures observed on CI:
`/bin/sh: 1: tsc: not found` during `yarn run pkg`, caused by
incomplete typescript extraction into per-module node_modules.
Fix at two layers:
1. Maven reactor chain (primary): add reactor-only pom <dependency>
entries (type=pom, scope=provided, wildcard exclusions) to form
ui-ngx -> msa/web-ui -> msa/js-executor
so the MultiThreadedBuilder schedules them strictly serial,
regardless of -T thread count. msa/web-ui already had a real
dependency on ui-ngx; only one new fake link was needed.
2. Yarn-level mutex (defense in depth): add `--mutex network` to
`yarn run pkg` (msa/web-ui, msa/js-executor) and
`yarn run build:prod` (ui-ngx), so single-module builds outside the
reactor chain (`mvn -pl msa/<module>`) still serialize against any
other yarn process on the agent.
Comment in msa/pom.xml updated: the previous "Modules order is
important..." note was misleading - module order in the reactor does
not enforce serialization under -T; the dependency edges do.
Remove <pkg.skip.bootjar>false</pkg.skip.bootjar> from all child
module <properties> blocks. The root POM already defaults it to false,
and child declarations block the skip-pkg profile override, so
-Dpkg.skip=true was never actually skipping spring-boot:repackage.
Also remove the unused surefire.version property (superseded by
maven-surefire-plugin.version).
The com.spotify:dockerfile-maven-plugin:1.4.13 is deprecated and broken
on modern macOS (Apple Silicon) due to its Java HTTP client being
incompatible with current Docker Desktop socket/API.
Replace the Java-based plugin with exec-maven-plugin calling the docker
CLI directly — the same approach already used by the multiarch push
profiles (push-docker-amd-arm-images).
All existing Maven property contracts preserved:
- dockerfile.skip (default true) controls docker build
- push-docker-image profile for single-arch push
- push-docker-amd-arm-images profiles unchanged (already use exec)
Introduces four independent flags to skip individual packaging artifacts:
-Dpkg.skip.bootjar=true skip spring-boot repackage (*-boot.jar)
-Dpkg.skip.deb=true skip Gradle buildDeb + Maven attach-artifact
-Dpkg.skip.rpm=true skip Gradle buildRpm
-Dpkg.skip.zip=true skip maven-assembly-plugin Windows ZIP
Adds -Dpkg.skip=true as a single convenience flag that sets all four
at once. msa/pom.xml mirrors the skip-pkg profile to override its own
<pkg.deb.phase>package</pkg.deb.phase> property (child POM properties
have higher priority than parent profile properties in Maven).
msa/* docker modules used ${basedir}/../.. (non-canonical) for main.dir.
maven-enforcer-plugin 3.5.0's osIndependentNameMatch() compares
file.toURI() vs file.getCanonicalFile().toURI() — these differ when the
path contains '..', causing RequireFilesExist to report false-negative.
Fix: replace ${basedir}/../.. with ${maven.multiModuleProjectDirectory}.
When building with -T6, multiple JS modules run yarn install concurrently.
The --mutex network flag serializes yarn processes, but if node_modules from
a previous build (or a different branch/version) is left on disk, yarn may
skip reinstalling packages — including devDependencies — treating the stale
state as up-to-date. This causes tools like tsc to be missing at build time.
Configure maven-clean-plugin to delete node_modules during mvn clean for
all JS modules (ui-ngx, msa/js-executor, msa/web-ui). Yarn restores from
its global cache (~/.cache/yarn), so the overhead is relinking only.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Viacheslav Klimov
Sergey Matvienko
Vladyslav_Prykhodko
Igor Kulikov
Andrii Shvaika