CodeVetter · Repo Unpack · Testing signals
ohmyzsh/ohmyzsh
Testing is thin for a project of this reach. CI (main.yml) does only `zsh -n` syntax checking over the entrypoint, lib files, plugin entrypoints/completions, and themes — no behavioral test runs. Real tests exist but are scattered and not wired into workflows: lib/tests/cli.test.zsh exercises the plugin-disable awk script, and a few plugins (alias-finder, dotenv) ship zunit suites. The installer gets its own matrix test on ubuntu+macos, and all workflows run step-security/harden-runner in audit mode.
- main.yml's only test step is a `zsh -n` syntax sweep over ./oh-my-zsh.sh, lib/*.zsh, plugins/*/*.plugin.zsh, plugins/*/_*, and themes/*.zsh-theme on ubuntu-latest; the job is gated on github.repository == 'ohmyzsh/ohmyzsh'.
- lib/tests/cli.test.zsh duplicates the plugin-disable awk program inline and tests it against oneline/multiline/mixed plugins=(...) formats, asserting both `zsh -n` validity and exact diff output via run_awk_and_test.
- The awk script tested by lib/tests/cli.test.zsh is a copy of the one embedded in _omz::plugin::disable in lib/cli.zsh, so the test validates a clone of the logic rather than the shipped code path. (inferred)
- Plugin-level tests exist in zunit format: plugins/alias-finder/tests/test_run.sh (@setup/@test/@assert blocks) and plugins/dotenv/tests/{basic-parsing,compatibility,security}.zunit.
- Neither the zunit suites nor cli.test.zsh are invoked by any workflow; grep of .github/workflows shows only the syntax-check job and the installer test, so these tests run only when a developer runs them manually. (inferred)
- installer.yml runs `sh ./tools/install.sh` on ubuntu-latest and macos-latest on pushes touching tools/install.sh, then deploys install.sh to Vercel (install.ohmyz.sh) on master via `vc deploy --prod` with VERCEL_* secrets.
- Every workflow pins actions by SHA and prepends step-security/harden-runner with egress-policy: audit; permissions are minimal (contents: read) except dependencies.yml which grants contents: write for pushing update branches.
- scorecard.yml runs OpenSSF Scorecard analysis weekly and on master pushes, uploading results to the code-scanning dashboard (security-events: write).
- dependencies.yml runs updater.py weekly: it reads .github/dependencies.yml entries (upstream repo/branch/pinned version + precopy/postcopy shell), fetches upstream releases, and opens/commits vendored-plugin updates authenticated as the ohmyzsh[bot] GitHub App.
- project.yml uses pull_request_target with an empty default permission set plus a GitHub App token to add new issues/PRs to the ohmyzsh org Project board and set Plugin/Theme fields.
- CONTRIBUTING.md mandates Conventional Commits (type(scope)!: subject) because tools/changelog.sh generates the user-facing changelog from commit subjects — so commit-message discipline is itself part of the test/release pipeline.
- No test covers oh-my-zsh.sh init order, compfix/compinit handling, upgrade.sh, check_for_upgrade.sh, or lib/git.zsh prompt parsing — the riskiest shell logic is verified only by the syntax sweep. (inferred)