PMM-15031: Email logo

[mattiasimonato]

https://jira.percona.com/browse/PMM-15031

• PMM-15031: Host the PMM email logo on the docs site percona/pmm#5829
• PMM-15031: Point PMM emails at the new logo URL percona/grafana#921

[JNKPercona]

Server docker: perconalab/pmm-server-fb:PR-4543-018d0e8
Client docker: perconalab/pmm-client-fb:PR-4543-018d0e8
Client tarball: https://s3.us-east-2.amazonaws.com/pmm-build-cache/PR-BUILDS/pmm-client/pmm-client-PR-4543-018d0e8.tar.gz
Staging instance: https://pmm.cd.percona.com/job/pmm3-aws-staging-start/parambuild/?DOCKER_VERSION=perconalab/pmm-server-fb:PR-4543-018d0e8&CLIENT_VERSION=https://s3.us-east-2.amazonaws.com/pmm-build-cache/PR-BUILDS/pmm-client/pmm-client-PR-4543-018d0e8.tar.gz

[JNKPercona]

API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/7130/

[JNKPercona]

Looks like there are outdated source branches.
Please update them and restart the job
percona/pmm#5829
percona/grafana#921

[travagliad]

Looked at the red FB run 33638736972 — the single failure, PMM-T1087 in E2E / Instances UI tests, is a pmm-qa setup issue, not your change. The test needs postgresnodb to have no postgres database so PMM's pre-add connection check rejects the service; that run's pmm-managed.log shows the database was there (database_list:"postgres" database_list:"not_default_db"), so PMM correctly accepted the service. Reproduced on your FB server image: with that database absent the API returns exactly the asserted Connection check failed: pq: database "postgres" does not exist, and with it present the service is added — the product is fine either way.

The setup step that drops it is a one-shot psql with no retry and no verification, and docker compose up -d never sees its exit code. Fix in percona/pmm-qa#1293. I have also re-run the failed job on this run so your PR can go green in the meantime.

---

Generated by Claude Code

[travagliad]

FB Tests went red twice on the same check (E2E / Instances UI tests / e2e tests: @fb-instances), both times for reasons unrelated to your change. Attempt 1 died in setup, before any test ran: external_setup.sh got Unable to establish SSL connection fetching redis_exporter-v1.14.0.linux-386.tar.gz from GitHub release assets, and the script has no retry, so external_setup.yml failed — that asset serves fine now (HTTP 200, 3,046,958 bytes) and the external setup reproduces clean on a throwaway VM against this PR's own perconalab/pmm-server-fb:PR-4543-018d0e8 image (playbook execution successful, failed=0, both external services registered).

On the re-run of the failed job, setup passed and 31/32 tests passed; only PMM-T1087 failed, and it asserted against a toast naming arbustum_service while the attempt under test had filled arca_service — Feature('Remote DB Instances') carries .retry(1), so the assertion read a toast from a different execution of the test body rather than the click it was verifying. PMM itself behaves correctly here: on the same FB image, both the REST API and the real Add-remote-PostgreSQL UI form return Connection check failed: pq: database "postgres" does not exist (3D000)., the QA setup reliably drops the postgres database (8/8 fresh compose runs), and PMM-T1087 passes when run on a clean box.

Verdict: no product bug and nothing implicating your change. PMM-QA is picking up both test-side issues — the un-retried release-asset download in external_setup.sh, and PMM-T1087's retry/stale-toast assertion race. I have used the one permitted re-run, so please re-run FB Tests yourself if you need a green check before merge.

---

Generated by Claude Code