Replace the npx-spawned vally-cli process with a direct call to the
@microsoft/vally core library in the external plugin quality gates scripts:
- Add @microsoft/vally as a devDependency in package.json
- Import runLint and LintConsoleReporter from @microsoft/vally
- Replace runVallyLintGate() process spawn with async API call:
- runLint({ rootPath }) returns structured LintResults
- LintConsoleReporter with a Writable capture stream collects
text output without printing to stdout
- Make runExternalPluginQualityGates() async (propagated to
runExternalPluginPrQualityGates() and both main entry points)
- Use Promise.all in runExternalPluginPrQualityGates() for parallel
plugin checks
- Fix remaining skill_validator_status reference in pr-quality-gates
summary string (now vally-lint=...) and YAML workflow table header
- Add 'npm install @microsoft/vally' step to both calling workflows
This removes a layer of indirection (Node -> npx -> CLI -> library)
and replaces it with a direct in-process library call, which is faster,
more reliable, and gives structured access to lint results.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Replace the downloaded skill-validator binary with
px @microsoft/vally-cli lint
in the external plugin quality gates pipeline:
- Remove downloadSkillValidator() and SKILL_VALIDATOR_ARCHIVE_URL constant
- Replace uildSkillValidatorArgs() +
unSkillValidatorGate() with
uildVallyLintArgs() +
unVallyLintGate() that run
px vally-cli lint
per resolved skill directory (falling back to the full plugin root when no
specific skill paths can be resolved from plugin.json)
- Rename result keys skill_validator_status / skill_validator_output
to ally_lint_status / ally_lint_output throughout both
ng/external-plugin-quality-gates.mjs and ng/external-plugin-intake.mjs
- Update PR comment markdown to show 'vally lint' instead of 'skill-validator'
- Update CONTRIBUTING.md prose references accordingly
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The install smoke gate was hardcoding .github/plugin/plugin.json as the
expected manifest path after copilot plugin install, which caused a false
ail for plugins whose manifests live at plugin.json (root) or
.plugins/plugin.json instead of the Copilot CLI convention.
Replace the hardcoded path with a call to the existing indPluginJson()
helper that already probes all three candidate locations in priority order.
Separate the 'install directory missing' check from 'no manifest found' so
error messages surface the actual root cause.
Also fix a .plugin/ → .plugins/ typo in EXTERNAL_PLUGIN_ROOT_MANIFEST_PATHS
(external-plugin-validation.mjs) which caused the error message shown to
submitters to reference a path that indPluginJson never actually checks.
Add cross-reference comments on both constants so they stay in sync.
Closes: reported in issue #1837
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* fix: skill-validator invocation for .github/plugin/plugin.json convention
The skill-validator --plugin mode looks for plugin.json at <dir>/plugin.json,
but external plugins (and the Copilot CLI) place it at .github/plugin/plugin.json.
This caused every external plugin with skills or agents to fail the skill-validator
gate with a misleading 'No plugin.json found' error, even when the install smoke
test passed correctly.
Extract buildSkillValidatorArgs() which reads plugin.json from
.github/plugin/plugin.json, resolves skills/agents paths relative to the plugin
root, and invokes skill-validator with --skills/--agents instead of --plugin.
Falls back to --plugin if the conventional path is not present.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* fix: also check .plugins/plugin.json and root plugin.json locations
Extend buildSkillValidatorArgs to probe three candidate plugin.json locations
in priority order before falling back to --plugin:
1. .github/plugin/plugin.json (Copilot CLI convention)
2. .plugins/plugin.json
3. plugin.json (root — also the skill-validator's native --plugin expectation)
Extract findPluginJson() and PLUGIN_JSON_CANDIDATES constant so the list is easy
to extend. Paths in plugin.json are always resolved relative to the plugin root
regardless of where the manifest lives.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Aaron Powell