Diagnostics

renmy doctor diagnoses your project setup.

renmy doctor runs a set of checks on your Salesforce project and reports what is wrong, with a fix for each issue. It works like brew doctor or gh auth status.

What it checks

Eight diagnostics run in order. Each one reports pass, warning, or failure with a ready-to-run fix.

CheckValidatesSeverity
nimbus.properties foundProject configuration file exists in the project rootfail
Schema files foundSObject schemas have been synced from an org into .nimbus/schemas/warn
Stubs directory existsA stubs/ directory is present for managed package and external dependency stubswarn
Database connectivityEmbedded PostgreSQL can start and accept connectionsfail
License statusCurrent license tier (Free / Pro / Team) and expiry date if applicablewarn
Apex test classes found@isTest classes exist under the project source directoriesfail
Config syntaxAll keys in nimbus.properties are recognized - unknown keys reportedwarn

Example output

Clean project, one unknown config key. The worker count is nimbus.test.parallel.

$ renmy doctor
✓ nimbus.properties found
✓ Schema files found (14 files)
✓ Stubs directory exists
✓ Database connectivity OK
✓ License: Pro (expires 2027-03-01)
✓ Apex test classes found (8 classes)
⚠ Unknown config key: nimbus.parallelism
→ Remove or rename the unknown key(s). Run `renmy config properties` to see all valid keys.
1 warning(s) Run `renmy doctor --verbose` for details.

CI onboarding

Gate your pipeline on a clean setup before running tests. If renmy doctor exits 1, the test run never starts, and the failure message tells the developer what to fix.

bash
# In your CI pipeline - fail fast with a clear error
renmy doctor && renmy test
Exit codes: 0 when all checks pass or warn. 1 when any check fails. Warnings are advisory and do not affect the exit code. Only hard failures (missing config, no test files, broken database) cause a non-zero exit.

GitHub Actions example

yaml
- name: Verify setup
  run: renmy doctor

- name: Run tests
  run: renmy test --coverage --coverage-report coverage.xml

Common issues

Most first-run failures fall into one of these categories.

  • nimbus.properties not found
    Run renmy config init from your project root (the directory containing sfdx-project.json) to generate a starter configuration file.
  • No schema files found
    Schema files are populated by renmy sync -o <org>. If you don't have org access in your environment (e.g. CI), commit the .nimbus/schemas/ directory to source control after syncing locally.
  • Database connectivity fails
    The embedded PostgreSQL process may be in a broken state. Run renmy db reset to stop any running process and reinitialize the data directory. If that doesn't help, run renmy reset for a full clean slate.
  • No @isTest classes found
    renmy runtime scans all .cls files under your project for the @isTest annotation. Make sure your test classes are inside the package directories listed in sfdx-project.json and aren't excluded by a nimbus.test.exclude pattern.
  • Unknown config keys reported
    Run renmy config properties to list every supported key. Profile-prefixed variants like %ci.nimbus.test.parallel are valid - only the base key is checked. Typos and removed keys from older versions of renmy runtime are the most common cause.