feat(pipedream): add edge pipeline group for edge/default and the 15 PoPs

[mwarkentin]

This is step 1 of 3. It must merge and be tagged v3.1.0 before the getsentry/ops PR can build. See "Rollout order" below.

Why

The edge region — edge/default plus the 15 edge/pop-* clusters — has no generated GoCD pipeline applying any of its materialized manifests today. Everything there is applied by hand.

This isn't a missing config value, it's structural. pipedream.render iterates getsentry.group_order → get_targets(group) → pipeline_groups, and that set has no edge and no PoP entry. include_regions can't help either: per should_include_region it only re-admits regions already in default_excluded_regions, so there is no string you can put in a service's include_regions today that produces an edge pipeline.

Grouping

Three groups, chained in this order:

Group	Regions	Why
edge	edge	The sentry-edge primary cluster. An ordinary region cluster, so it gets an ordinary single-region group — exactly like us, de, s4s2, control.
edge-pop-canary	edge-pop-rr	pop-rr is the canary cluster for the PoP fleet. The PoPs have no in-cluster canary deployments the way the SaaS regions do; one whole cluster plays that role. Alone in its group, so sequential group chaining makes it a real gate for the rest.
edge-pop	the other 14	One group means parallel jobs in one pipeline. There is no meaningful order between PoPs, and alphabetical order in particular implies a sequencing that doesn't exist. Adding a PoP needs no ordering decision.

Resulting chain: … → snty-tools → edge → edge-pop-canary → edge-pop → st.

A side benefit of the 14 sharing a group: PIPEDREAM_GROUP_REGIONS lets an operator deploy a subset from "Trigger with options". Single-region groups skip that gate, so it wouldn't have been available if each PoP were its own group.

The edge groups trail the SaaS regions because these are ingest-path clusters — they should only move after the regions they front are known good.

The PoPs as pseudo-regions

The 15 PoPs are modelled as pseudo-regions (edge-pop-au, …) the way the uptime clusters already are, so each cluster gets its own diff/apply job rather than one job fanning out internally.

Default-exclusion

All 16 edge regions go into default_excluded_regions.

This part is not optional. Without it, adding the groups hands every pipedream service — getsentry, snuba, taskbroker, ~50 of them — an edge pipeline for manifests they don't render. Only 7 services render anything into edge at all.

To be clear about what this is and isn't: it's the same treatment control, prod-control and snty-tools already get, and for the same reason. Those are ordinary region clusters too. Default-exclusion is about "most services don't deploy here", not about edge being structurally special — edge is a plain single-region group like any other.

Implementation note

The region lists are file-level locals, not fields. pipeline_groups gets copied into other objects (test/testdata/fixtures/getsentry/groups.jsonnet does exactly this), which rebinds self — a self.edge_regions reference fails to resolve there.

Also exports default_excluded_regions, plus edge_regions (all 16) and edge_pop_regions (the 15 PoPs) so consumers don't filter by hand. ops' render_with_pre_diff kept its own copy of the excluded-regions list, which was already a latent drift hazard and this change would have triggered it (details in the ops PR).

Testing

npm run test — 59 pass (was 57).

The evidence that the default-exclusion landed correctly is what didn't change: all 48 pipedream goldens are byte-identical. The only golden that moved is getsentry/groups, the group registry itself. No service gained a pipeline.

New fixture pipedream/include-edge.jsonnet opts into all 16 and pins the structure:

deploy-example-edge              1 job  (deploy-edge)          upstream: us2
deploy-example-edge-pop-canary   1 job  (deploy-edge-pop-rr)   upstream: edge
deploy-example-edge-pop         14 jobs (parallel)             upstream: edge-pop-canary

Rollout order

1. This PR → merge, then tag v3.1.0.
2. getsentry/devinfra-deployment-service#899 — region configs. Independent of this; can merge any time.
3. getsentry/ops#22360 — pin bump, region mapping, per-service opt-in, cluster access. Needs the tag from step 1.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit c2e9885. Configure here.}

[mchen-sentry]

This should be fine, but I think we will have to update post-deploy-migrations's exclude regions list to include edge.

If this happens more frequently we should rework our overwrite exclude list process to an explicit include one instead.

[mwarkentin]

@mchen-sentry is that required even if the edge stuff is excluded by default?

[mchen-sentry]

Yes, because post-deploy-migrations overrides the default exclude list.

[mwarkentin]

I didn't have time to get this over the finish line, and am off on PTO. If someone wants to get it merged, feel free!