gemini-cli - 💡(How to fix) Fix CI: fail PR when @google/gemini-cli npm tarball exceeds size threshold [1 participants]

Summary

Add a CI check that fails a PR if the published npm tarball for @google/gemini-cli (or @google/gemini-cli-core) would exceed a known-safe size threshold. Catches the kind of regression that produced #25507 (an npm publish E413 from wombat-dressing-room) at PR review time instead of at release time.

Why is this needed?

The chain that broke Release: Promote for ~7 days:

1. PR #25342 added 5 cross-platform ripgrep binaries (~21 MB raw) into bundle/vendor/ripgrep/.
2. The PR template only asks for "validated on macOS / npm run" (which the author checked). Nothing in the template or CI surfaced the published-tarball size.
3. The change merged.
4. The first nightly to include the change failed with E413 (auto-filed #25507, priority/p0, release-failure — closed without action).
5. Six subsequent nightlies stalled in the prod environment approval queue, silently.
6. Eight days later, a manual Release: Promote finally surfaced the failure to a human.

A CI guard at step 2 would have prevented all of this with a single line of red on the PR.

Proposed plan

Add a job to .github/workflows/ci.yml (or a small new workflow that runs on PRs touching scripts/, packages/*/package.json, esbuild.config.js, and anything that changes bundle composition):

tarball_size:
  name: 'Check npm tarball size'
  runs-on: 'gemini-cli-ubuntu-16-core'
  needs: 'merge_queue_skipper'
  if: "github.repository == 'google-gemini/gemini-cli' && needs.merge_queue_skipper.outputs.skip == 'false'"
  steps:
    - uses: 'actions/checkout@…'
    - uses: 'actions/setup-node@…'
      with: { node-version-file: '.nvmrc', cache: 'npm' }
    - run: 'npm ci'
    - run: 'npm run bundle'
    - run: 'node scripts/prepare-npm-release.js'
    - name: 'Check @google/gemini-cli tarball size'
      run: |
        SIZE_BYTES=$(npm pack --dry-run -w @google/gemini-cli --json 2>/dev/null \
          | jq -r '.[0].size')
        SIZE_MB=$(awk -v b="$SIZE_BYTES" 'BEGIN { printf "%.1f", b/1048576 }')
        # wombat-dressing-room's hard limit is somewhere in the 25-28 MB range;
        # leave headroom.
        LIMIT_MB=22
        echo "@google/gemini-cli tarball: ${SIZE_MB} MB (limit ${LIMIT_MB} MB)"
        if (( $(echo "$SIZE_MB > $LIMIT_MB" | bc -l) )); then
          echo "::error::@google/gemini-cli tarball is ${SIZE_MB} MB — exceeds the ${LIMIT_MB} MB safety threshold for wombat-dressing-room. Consider trimming bundled assets, or moving large native binaries to platform-specific optionalDependencies."
          exit 1
        fi
    - name: 'Check @google/gemini-cli-core tarball size'
      run: |
        # Same check, lower threshold (core's historical baseline is ~10 MB).
        ...

Key design decisions

• Threshold tuning. Set the limit ~10–15% below the actual wombat ceiling so we get warned before a release fails. Values above (~22 MB for cli, ~15 MB for core) are starting points that match the current healthy baselines from #25841.
• Run on PRs, not just main. The whole point is to catch this in review, not after merge.
• Output is actionable. The error message names the likely fix (move binaries to optionalDependencies) so reviewers / authors don't have to reverse-engineer it.
• Don't gate the merge queue on this if the threshold is hit by a legitimate growth. The label-bypass pattern (area/release-known-bigger-tarball or similar) lets release-aware PRs override after a maintainer reviews.
• Optional follow-up: also report the tarball size as a status comment on the PR so authors see the trend even when below the limit.

Estimated effort

~2–3 hours, including PR template tweak to add a "tarball size impact" item to the bundle-affecting PR checklist.

Related Issues

• Caused by: #25342 (silently grew the tarball)
• Surfaced via: #25507 (auto-filed nightly failure)
• Mitigated by: #25841 (the actual unblock; doesn't prevent recurrence)

Additional context

• npm pack --dry-run --json provides exact bytes; no parsing of npm notice output needed.
• The bundle_size job in .github/workflows/ci.yml already does diffing for the SEA bundle; this would be its npm-tarball cousin.
• The release-infra check is layered: this CI job catches at PR time; the Release: Promote job will still legitimately fail at publish time if someone bypasses the check, so we're not removing the safety net, just adding an earlier one.