Docs / Collision-aware PR reviews
Collision-aware PR reviews
A plain terraform plan can tell you a subnet is being created. It can't tell you what CIDR it'll get, or how full that leaves the shared pool - the allocation happens dynamically, server-side, and only nxip has visibility into everyone else's. This closes that gap, in the PR, before anyone applies anything.
What a reviewer actually sees
Real output, from a real PR against a nested subnet - a team's subnet auto-resolving onto akind-tagged region block rather than a pool directly:
| Resource | Status | CIDR | Destination | Utilization |
|---|---|---|---|---|
nxip_subnet.payments_production | ✅ | 10.101.16.0/24 | subnet us-east-1 region block | 12% → 18% |
That's the point of it: not just "this will create a /24" (Terraform's own plan already says that), butwhich /24, landing where, and what that does to the space everyone else is sharing. A reviewer sees this without an nxip account, without leaving GitHub.
Why it matters at review time, not apply time
If the destination is getting close to full, that's a conversation to have before merging, not an allocation failure discovered days later. Turn on fail-on-predicted-failure and a predicted failure (pool full, tier limit) fails the PR's CI check outright - with branch protection requiring it, that PR can't merge until it's addressed. The outage-shaped problem becomes a red check in review, not an incident.
Set it up
One workflow file, one secret. Nothing else about how you use Terraform changes.
name: nxip plan preview
on:
pull_request:
paths:
- "**.tf"
permissions:
contents: read
pull-requests: write
jobs:
preview:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v3
- run: terraform init
- run: terraform plan -out=tfplan
- run: terraform show -json tfplan > plan.json
- uses: uk-sw/nxip-terraform-plan-action@v1
with:
plan-json-path: plan.json
nxip-api-key: ${{ secrets.NXIP_API_KEY }}It only reads the plan JSON - it never runs Terraform itself and never touches your cloud credentials. Push a second commit to the same PR and it edits its existing comment rather than posting a new one.
pull_request_target with a plan built from the PR's own branch - that runs with your repo's secrets against code from the fork, handing a fork PR author your API key. Usepull_request, as above.Who this is actually for
Worth being direct about this rather than overselling it: this only ever fires on a Pull Request. If you apply directly from your own machine - which is exactly what our own quick start teaches, and a completely normal way to use nxip - there's no PR for it to comment on, and that's fine.
It earns its keep on a team that already reviews infrastructure changes before applying them, where shared address space is genuinely contested enough that "did this just push us to the edge" is a real question. If you're the only one touching the Terraform, or you've got room to spare, this simply won't come up - nothing else about nxip requires it.
Set up the provider itself first if you haven't - the Terraform quick start gets a real pool and subnet running in a couple of minutes. Already have infrastructure to bring under management? See importing existing infrastructure.
