Follow-up from apm-review-panel on #40 (#40 (comment)).
Why
PR #40 adds five new pass-through inputs (marketplace, marketplace-path, json-output, offline, include-prerelease) plus a misuse-rejection branch and a workspace-containment check. All of it is covered by unit tests against a mocked @actions/exec. None of it is covered by an actual apm pack invocation in CI.
The current alpha / beta / gamma matrix in .github/workflows/test.yml runs the installer path against a real CLI, but it does not exercise the new pack inputs end-to-end. So a real-CLI regression on flag names, exit codes, or stdout shape could ship without us seeing it until a downstream consumer files a bug.
What to add
A new job (or extension of the existing pack matrix) that:
- Installs the released APM CLI (
microsoft/apm-action@v1 setup-only mode, or pinned binary).
- Scaffolds a tiny fixture covering each new input:
- single-plugin (current default path)
- marketplace-only project with
outputs: map (marketplace: 'auto', json-output: 'reports/pack.json')
- hybrid (plugin + sibling marketplace)
- Asserts:
- the action produces the right artifact set for each fixture
bundle-path output is empty exactly when expected (marketplace-only)marketplace-path overrides land where requested- the misuse-rejection branch fails with a useful message when
marketplace is used on a single-plugin project
--offline and --include-prerelease reach the CLI (assert via apm pack --json shape if possible)
Why this is a separate issue, not part of #40
Adding a real-CLI matrix is non-trivial: it needs a fixture catalog, a CLI install step, and probably a separate workflow file. Doing it inside #40 would balloon the PR diff and gate the v1.8.0 tag on infrastructure work that does not change the action's behaviour. The pass-through inputs themselves are mechanical (5 flag forwards + 1 validation branch) and covered by the unit suite; the e2e matrix is an additional confidence layer, not a correctness gate.
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com
Follow-up from apm-review-panel on #40 (#40 (comment)).
Why
PR #40 adds five new pass-through inputs (
marketplace,marketplace-path,json-output,offline,include-prerelease) plus a misuse-rejection branch and a workspace-containment check. All of it is covered by unit tests against a mocked@actions/exec. None of it is covered by an actualapm packinvocation in CI.The current alpha / beta / gamma matrix in
.github/workflows/test.ymlruns the installer path against a real CLI, but it does not exercise the new pack inputs end-to-end. So a real-CLI regression on flag names, exit codes, or stdout shape could ship without us seeing it until a downstream consumer files a bug.What to add
A new job (or extension of the existing pack matrix) that:
microsoft/apm-action@v1setup-only mode, or pinned binary).outputs:map (marketplace: 'auto',json-output: 'reports/pack.json')bundle-pathoutput is empty exactly when expected (marketplace-only)marketplace-pathoverrides land where requestedmarketplaceis used on a single-plugin project--offlineand--include-prereleasereach the CLI (assert viaapm pack --jsonshape if possible)Why this is a separate issue, not part of #40
Adding a real-CLI matrix is non-trivial: it needs a fixture catalog, a CLI install step, and probably a separate workflow file. Doing it inside #40 would balloon the PR diff and gate the v1.8.0 tag on infrastructure work that does not change the action's behaviour. The pass-through inputs themselves are mechanical (5 flag forwards + 1 validation branch) and covered by the unit suite; the e2e matrix is an additional confidence layer, not a correctness gate.
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com