868e2f8f32
Buzz push currently selects an application profile, such as `dogfood`, during client registration. We want each gateway to serve one Apple app configured by the operator instead. This removes profile selection from the client, relay, and gateway, while allowing internal and public gateways to use their own Apple identities. This PR implements that model in the Buzz source and upstream deployment chart. Discovery, enrollment, grants, and leases no longer carry an application-profile selector. Each gateway has one configured Apple application and APNs transport. The protocol changes are incompatible with the old registration format, so relays advertise `buzz-push-v1` instead of `nip-pl`. Old clients do not discover the new push capability. Updated clients use separate Keychain records and register again. The [push notes](https://github.com/block/buzz/blob/push-capability-v1/docs/buzz-push.md) describe the experimental contract. Landing this PR is the first step. Publish the matching gateway image and upstream chart, then land the [shared chart update](https://github.com/squareup/cash-helm-charts/pull/5740) and [gateway deployment update](https://github.com/squareup/builderbot-platform-core-infrastructure/pull/1085). Before cutover, stop old gateway instances and check legacy registration state. Migrations refuse to proceed if old gateway installations or active relay leases remain; they do not delete that state. Physical-device verification remains necessary before production activation. ### Validation Gateway and focused Flutter push tests pass, as do the Swift package, simulator build, and native notification/enrichment tests. A local relay advertises `buzz-push-v1` without `nip-pl` or `app_profiles`. The PostgreSQL suite passed 868 tests; its two migration-test failures were corrected and pass a focused rerun together with the gateway cutover guard. Chart rendering and release-contract checks pass. Desktop JavaScript tests, desktop and web builds, native desktop compilation, mobile analysis/tests, and desktop native tests pass. The full Rust unit lane and prescribed `just test` command pass, including workspace integration tests against task-isolated local services. The production overlay now requires an explicitly supplied APNs topic, with omission and rendered-value regression coverage. The corrected Swift checksum assertion passes the complete package suite: 78 XCTest tests and 42 Swift Testing tests. No physical-device enrollment or production cutover is claimed. Local merge validation: the embedded migration test and formatting pass after reserving profile migration 0060 behind rollback migration 0059. The local pre-push Rust lane failed ACP timing/steering tests (`idle_resets_on_stdout_activity`, `keepalive_resets_idle_past_deadline`, and the failed/missing-outcome steering tests). ACP and its dependency manifests are unchanged by this branch; all four pass in an isolated single-thread rerun. The documented local-check exception skips only the Rust pre-push lane for publication; required CI remains mandatory. Mobile and desktop pre-push lanes passed. Combined migration validation: after rollback 0059 landed, the main merge preserves profile migration 0060 and both embedded migration assertions. The focused migration test and formatting pass. The next local push again failed only the unchanged ACP idle/keepalive timing tests (1053 passed, 2 failed, 3 ignored); other lanes passed. Publication uses the same documented local Rust-lane exception; required CI remains mandatory. Follow-up review fix: removed the legacy profile column from the copied-lease fixture. All four event-follow-up contract tests pass on isolated PostgreSQL databases, covering desired and migrated schemas in dual and app-only modes. Formatting passes. Publication retains the prior passing local-lane evidence and uses the authorized pre-push exception for the known unrelated ACP timing failures; required CI remains mandatory. --------- Signed-off-by: Tom Brow <tomb@block.xyz>
Buzz push gateway chart
Platform-managed runtime integration
podLabels, serviceAccountName, and terminationGracePeriodSeconds configure
only runtime pods. Defaults retain the existing pod specification; the grace
period cannot be shorter than 60 seconds. Additional labels cannot override the
chart's name, instance, or component selectors. Migration settings remain separate.
A parent chart that supplies its own runtime NetworkPolicy can set
networkPolicy.enabled=false and networkPolicy.externalPolicyName to that
policy's name. The name is an explicit acknowledgement, not a cluster existence
check: the parent must render and validate a policy selecting the runtime pods
before deployment. Supplying a replacement name while the upstream policy is
enabled is rejected. The migration NetworkPolicy remains enabled independently.
External-policy releases must run tests/check-external-policy.rb on the
complete parent render including hooks, before install or upgrade. Helm 3
excludes hooks from its post-renderer input, so --post-renderer alone is not a
sufficient gate. Render without --no-hooks or resource filtering, using the
same chart, release name, namespace, values and capabilities as the deployment:
set -o pipefail
helm template RELEASE PARENT_CHART --namespace NAMESPACE -f VALUES.yaml \
| ruby tests/check-external-policy.rb --expect DEPLOYMENT POLICY NAMESPACE > validated-release.yaml
--expect is mandatory for external-policy deployment and CI invocations.
Provide the intended Deployment name, replacement policy name and release namespace
from deployment configuration, not by extracting the annotations being checked.
Repeat it for each external-policy Deployment. Missing Deployments or removed or
overwritten markers then fail closed. No-argument mode is only for renders that
intentionally have no external-policy requirement, such as default-mode tests.
For upgrade preflight, include --is-upgrade. Deployment automation must stop if
this pipeline fails and must not change the chart or rendering inputs between
validation and deployment. Run the post-renderer additionally during Helm
install/upgrade to check ordinary resources, but retain the full-render preflight
to detect hook collisions. GitOps render pipelines must validate the complete
hook-inclusive output before submitting it to their reconciler.
The Deployment records the required policy name. The gate rejects a missing,
misspelled, duplicate, wrong-namespace or non-selecting replacement, and requires
both ingress and egress isolation. It emits no manifests on failure and preserves
successful output byte-for-byte. Parent CI must run this same gate on its complete
render; a subchart-only render intentionally fails in external-policy mode.
The deployment owner must separately validate the allowed traffic and rolling drain.
Deployment annotations
Use deploymentAnnotations for Deployment metadata such as
secret.reloader.stakater.com/reload. These do not apply to runtime Pods or
migration Jobs. Values must be strings; buzz.block.xyz/release-namespace and
buzz.block.xyz/external-network-policy are reserved for chart policy ownership.