`mode: release` fails with "produced no .tar.gz" on apm >= 0.20 — release.ts missed the .zip fix from #47

Summary

mode: release is incompatible with apm CLI >= 0.20.0. It packs each package with apm pack --offline --archive but only ever looks for .tar.gz in the output directory. Since apm 0.20.0 changed --archive to emit .zip by default, the pack succeeds and the action then fails with a misleading error.

The .zip compatibility fix in #47 ("accept .zip archives produced by apm pack (apm 0.20+)") landed in bundler.ts and multibundle.ts, but release.ts was never updated.

To Reproduce

Any repo with an aggregator layout (plugins/<name>/apm.yml) using:

- uses: microsoft/apm-action@v1
  with:
    apm-version: latest      # or any explicit version >= 0.20.0
    mode: release
    release-tag: v0.0.2
    release-skip-publish: true

Actual behavior

[*] Built marketplace.json [claude] (3 package(s)) -> .claude-plugin/marketplace.json
##[error]APM action failed: apm pack in /home/runner/work/<repo>/<repo> succeeded but
produced no .tar.gz in /home/runner/work/<repo>/<repo>/dist. Verify that the package
has a 'dependencies:' block or primitives to bundle.

The suggested remedy is a red herring. The packages do have primitives to bundle — running the exact same command by hand in the same tree produces bundles just fine, they are simply .zip:

$ (cd plugins/base && apm pack --offline --archive -o ./dist)
$ ls dist
base-0.0.1.zip  boards-0.0.1.zip  dev-0.0.1.zip

Expected behavior

mode: release should discover the artifacts apm pack --archive actually produces on the installed CLI, regardless of whether that is .zip (apm >= 0.20) or .tar.gz (older CLIs).

Root cause

In release.ts at v1.10.0 (d723bb64ed70c135bbaf87d126b721dd2dae0439):

• L311 — passes '--archive' with no --archive-format
• L349-L353 — listTarballs() filters .tar.gz only:

  function listTarballs(dir: string): string[] {
    if (!fs.existsSync(dir)) return [];
    return fs.readdirSync(dir)
      .filter(n => n.endsWith('.tar.gz'))
  

• L317-L323 — empty result throws the message above

Meanwhile the same release already handles this correctly elsewhere — bundler.ts L364-L370:

 * emits .zip by default as of apm 0.20; older CLIs (and pipelines that opt
 * back in with --archive-format tar.gz) emit .tar.gz. The action accepts
 * ...
const ARCHIVE_EXTENSIONS = ['.zip', '.tar.gz'];

Upstream reference: microsoft/apm CHANGELOG 0.20.0 — "BREAKING: apm pack --archive now produces .zip by default instead of .tar.gz … (microsoft/apm#1720)".

Why there is no workaround

There is no --archive-format passthrough input — the string appears nowhere in action.yml or src/ except that one explanatory bundler.ts comment. So the only way to use mode: release today is to keep the apm CLI below 0.20.0. The action's pinned default (0.14.0) does that implicitly, which is likely why this has not been reported more widely: it only bites consumers who set apm-version explicitly.

Notably, apm's own Releasing from any CI docs — which describe mode: release as "a convenience wrapper for the canonical sequence above" — now use build/*.zip throughout and carry a caution block telling producers to migrate off .tar.gz. The wrapper can no longer reproduce the sequence it wraps.

Coupling with #55

#55 asks for the stale 0.14.0 default to be bumped. If that default moves to >= 0.20.0 before this is fixed, mode: release breaks for every consumer, including those who never set apm-version. These two should be resolved together, or this one first.

Suggested fix

Mirror the approach already taken in bundler.ts: make artifact detection format-aware rather than pinning --archive-format on the pack call (which, per that file's own comment, "would break older CLIs that do not know the flag"). Concretely, in release.ts:

• generalize listTarballs() to accept both extensions (the ARCHIVE_EXTENSIONS constant already exists in bundler.ts)
• update the error text at L320 so it no longer names .tar.gz specifically, and points at archive discovery rather than a missing dependencies: block
• the sha256 sidecar and gh release create paths are extension-agnostic already, so no further change should be needed

#41 (no e2e coverage of pack against a real CLI) is presumably why this slipped through.

Environment

• Runner: ubuntu-24.04
• Action: microsoft/apm-action@v1.10.0 (d723bb6)
• apm CLI: 0.28.0, installed via apm-version: latest

Start in src/release.ts at listTarballs() and the pack error path, then compare archive handling in src/bundler.ts, especially its accepted extensions. Update release artifact discovery and its error wording, then verify mode: release with apm 0.20+ .zip output and older .tar.gz output; completion means both formats reach the existing checksum and GitHub release paths.