Expect 48 files in pmm-admin summary zip (sep-provision.log)

[claude]

Failures fixed (investigator)

• source: Percona-Lab/pmm-submodules PR #4500 — run https://github.com/Percona-Lab/pmm-submodules/actions/runs/31565446567
• blocked-on: PMM-15280 Provision a Grafana service account for SEP pmm#5755 — DO NOT MERGE until that PR lands; this test now expects behavior that doesn't exist on main yet.
• tests:
  • cli/tests/generic.spec.ts:190 / @generic — "run pmm-admin summary --server-url --server-insecure-tls with https"

What failed

CLI / Integration / Generic was the only red job in that run, and its own
Run CLI tests step reported success — the failure surfaced one step later, when
launchable gate exited 1 on Actionable Failures | 1:

expect(received).toHaveLength(expected)
Expected length: 47
Received length: 48
  at cli/tests/generic.spec.ts:199

Root cause — a stale count in our test, not a product bug

The 48th file in the summary archive is server/sep-provision.log.

percona/pmm#5755 (PMM-15280, part of the
PMM-15205 SEP stack this FB builds) adds a sep-provision supervisord program whose stdout
goes to /srv/logs/sep-provision.log. PMM Server's logs.zip — and therefore
pmm-admin summary — now carries one more file.

It is not gated on SEP being enabled: the program is autostart = true and merely exits
early when PMM_ENABLE_SEP is unset, so supervisord creates the log either way. The CI job
starts the server with no SEP variables at all and still got 48.

That PR already updated PMM's own copy of this expectation (api-tests/server/logs_test.go
gained "sep-provision.log"); the hard-coded 47 here was the last stale copy.

Verification

Reproduced and fixed on a throwaway Linode VM following
.github/workflows/runner-integration-cli-tests.yml step for step — FB server image
perconalab/pmm-server-fb:PR-4500-38283f6 (the PR's current head build, one commit newer
than the failing run's d9f3741), the matching FB client tarball, and the same
--database pdpgsql=16 --database ps,ENCRYPTED_CLIENT_CONFIG=true setup:

• /srv/logs/ on the FB server contains sep-provision.log with SEP disabled.

• Before (spec at main): 1 failed — Expected length: 47 / Received length: 48,
  the same assertion and the same numbers as CI. Reading the archive directly confirmed the
  delta:

  total files: 48
  sep-provision present: True
  ['server/sep-provision.log']
  

• After (this branch, same VM): the test passes (1 passed). A full
  --grep "@generic|@unregister" run on this branch gave 43 passed, 13 skipped, 1 failed,
  the single failure being PMM-T2227 - Verify tarball upgrade reading
  process.env.PMM_CLIENT_VERSION as undefined — a variable my repro shell had not exported
  and CI does set; that test passed in the CI run this fix comes from, and this change cannot
  affect it.

The archive's other counted assertions are untouched and unaffected: the 10- and 8-file
ones are --skip-server (client-only), and the two 43-file ones sit inside permanently
test.skip(true, …) --pprof tests.

What this does and does not prove

The count is verified against a build that carries #5755. Until that PR merges, main still
produces 47 files, so this test is expected to fail on main — hence the draft status.
The gate for flipping it to ready is #5755 landing, after which the normal CLI runs confirm
it.

---

Generated by Claude Code