Skip to main content
These checks confirm engine changes before merge; run them from the Moqui framework checkout that contains the Darpan component unless a command states otherwise. Start with focused tests, then widen.

​
Common checks

Run the narrowest check that covers your change first, then widen. focused-test.sh picks test classes from the files changed since the base ref (default origin/main) and falls back to the full suite for anything it cannot map. Pass -n as the second argument to print the selection without running it. It is a faster inner loop, not a substitute for the full suite before you push. Tests tagged mysql cover InnoDB locking behaviour that the default H2 test database cannot reproduce. They are excluded from test, unitTest, and smokeTest.

​
Runtime baseline

Spark on JDK 21 needs a set of --add-opens JVM flags, plus -XX:+EnableDynamicAgentLoading and --enable-native-access=ALL-UNNAMED. The component’s test tasks pass them, and the production entrypoint exports them through JAVA_TOOL_OPTIONS. A local server needs the same flags; without them a compare fails at runtime. Production images are built from a separate, private deployment repository (darpan-docker-config). Its production entrypoint refuses to start unless the database connection (Moqui_DB_HOST, Moqui_DB_USER, Moqui_DB_PASSWORD, Moqui_DB_NAME), entity_ds_crypt_pass, and JWT_KEY are set. entity_ds_crypt_pass_old is optional and used only during a key rotation.

​
When to run broader checks

Run broader backend checks when a change touches:
  • Shared facade services
  • Entity definitions or seed data
  • Active tenant or permission behavior
  • Reconciliation run execution
  • Generated output descriptors or file locations
  • RuleSet compilation or execution
  • JSON schema validation or inference

​
Backend service review checklist

Backend engine changes are ready to merge when:
  • The owning XML service contract is clear.
  • Inputs and outputs are documented in the service definition.
  • Access checks run before scoped data is returned or mutated.
  • Entity queries include active tenant or company filters where required.
  • Groovy helpers do not hide normal service orchestration.
  • Generated outputs include both descriptor metadata and scoped file handling.
  • Tests cover the changed contract or processing path.

​
Expected service documentation

Backend service documentation includes:
  • Service name
  • Owning file
  • Inputs and outputs
  • Authentication and authorization expectations
  • Runtime side effects
  • Verification path

​
Troubleshooting

For backend failures, read the earliest meaningful backend log entry for the request. The final exception often hides the first contract or data-shape problem.