feat: Add team_integrations table

[DafyddLlyr]

What does this PR do?

• Adds a new team_integrations table
• Sets up sync script for this table

Why do we need this?

As we need to add environment details for Medway it seems sensible to start tidying this up and dropping the numerous env vars we have holding these details.

In future we could also store encrypted API keys here.

Why store staging_* and production_* values in one table?

Doing this means we don't need to manage an additional data sync from staging to Pizza environments (which currently has production data, but staging secrets). By only copying across the relevant column for the environment, we can avoid managing an additional data sync process. The slight compromise here is that if we allow the setting of these values in the Editor, we'll just need to ensure we just access the environment-appropriate column.

Next steps...

• Merge to production
• Populate table with values currently stored as env vars
• Test sync script from prod → staging (note - data sync will fail whilst team_integrations table is live on main but not production)
• Get env vars from db using feat: team.getBopsSubmissionURL() function planx-core#212
• Drop BOPS_SUBMISSION_URL_* env vars 🗑️

[github-actions]

🤖 Hasura Change Summary compared a subset of table metadata including permissions:

Tracked Tables (1)

• public.team_integrations permissions:

  	insert	select	update	delete
  api		➕

  4 added column permissions

  	insert	select	update
  api		➕ id ➕ production_bops_submission_url ➕ staging_bops_submission_url ➕ team_id

Updated Tables (1)

• public.teams

[github-actions]

Removed vultr server and associated DNS entries

[jessicamcinchak]

I know this is still draft, but was thinking about an interesting question related to this after dev call yesterday & curious how you're thinking about it too !

• Do you imagine that team_integrations table has different values on production and staging and is discluded from data sync?
• If we one day manage these values from the Editor, would folks expect to manage both their production & staging settings on production because that's where all content & settings are managed? That'd make saving to different environments very tricky!

[DafyddLlyr]

Ha! I hit these exact questions yesterday and wanted to discuss before taking this further!

I imagine these values certainly being per-environment (I've added a UNIQUE constraint to team_id).

We use staging secrets on Pizzas so to keep the current behaviour (Pizzas submitting to staging) we'd need to sync data from staging → Pizzas. This has a few complexities we'd need to consider - managing both staging and prod data syncs and slightly less current data on Pizzas.

Let's try and grab a few mins this morning sometime?

[DafyddLlyr]

Decisions from discussion this morning -

• A single table to track both staging and production values
• On sync, just copy staging values to staging and Pizzas
• (Future) In Editor, only expose variables for matching environment

[jessicamcinchak]

Looks good! Let's go for a prod deploy today 🙂