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:

ResourceStatusCIDRDestinationUtilization
nxip_subnet.payments_production10.101.16.0/24subnet us-east-1 region block12% → 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.

Never trigger this on 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.