ghcr.io/pdp-connect/pdpp/core:latest has not republished in ~5 days / 419 commits

[natea]

Summary

ghcr.io/pdp-connect/pdpp/core:latest — the image the project's own self-host docs point owners at — is significantly stale relative to main, and this is causing real, user-visible regressions to go unshipped indefinitely.

Evidence

• Ran docker run -d --name pdpp ... ghcr.io/pdp-connect/pdpp/core:latest today (2026-09-01) via a fresh container.
• docker inspect on the pulled image shows OCI labels: org.opencontainers.image.created: 2026-08-25T15:42:33.130Z, org.opencontainers.image.revision: 30962c21b37adb89d7082bf2efd93c8e87de24ae, org.opencontainers.image.version: 1.8.0.
• docker pull ghcr.io/pdp-connect/pdpp/core:latest on 2026-09-01 returns Status: Image is up to date — same digest, sha256:243190bc248056b.... The registry has not published a new :latest build since 2026-08-25.
• main's current tip is 9202f6b0 (2026-08-29 — likely later commits exist too since I only checked as of this filing).
• git compare 30962c21...main reports ahead_by: 419 — 419 commits have landed on main since the last published image.

Concrete user-visible fallout

Filed as a symptom in PDP-Connect/data-connectors#50 (cross-referenced there): the deployed image's apps/console/src/app/(console)/lib/ directory — containing connection-catalog.ts, source-setup-presentation.ts, and the isRunnableAddOffer catalog-visibility logic that fixed two prior real bugs (Signal and Venmo both silently missing from /sources/add despite being registered and owner-actionable) — does not exist in the deployed container's source tree at all (confirmed via docker exec pdpp find ... /lib → not found, grep -r isRunnableAddOffer /console → no matches). The deployed image predates that whole module. As a direct consequence, the WHOOP connector (shipped 2026-08-13, promoted to preview tier with a fully live-proven manifest) has never actually been visible to any owner running the officially published image, despite being correctly registered server-side (manifest reconcile logs confirm updated .../whoop from whoop.json on every boot) and despite the current main branch's catalog logic handling it correctly (traced the full chain: buildConnectionSetupPlan → owner_actionable projection → buildOwnerConnectorCatalog → isRunnableAddOffer, every check passes for Whoop on main).

This is presumably not limited to Whoop — any owner-visible fix or feature merged in the last 419 commits is equally unshipped to anyone pulling :latest today.

Ask

• Check whatever CI/release workflow is supposed to build and push ghcr.io/pdp-connect/pdpp/core:latest on merge to main (or on a release tag) — it appears to have stalled, failed silently, or is gated on something (a version bump / release-please PR / manual trigger) that hasn't fired since 2026-08-25.
• Once unblocked, republish :latest so self-hosted owners pulling the documented image actually get current main.
• Consider alerting/monitoring on this specific failure mode going forward (e.g. a CI check that fails loudly if :latest's embedded revision drifts more than N commits behind main), since this kind of silent staleness is hard for an owner to detect from outside the container — I only found it by docker exec-ing in and diffing the deployed source tree against GitHub.

Related

• whoop connector missing from Add Source catalog despite preview-tier public_listing data-connectors#50 — the Whoop-connector symptom that led to this discovery