Skip to content

feat(multi-env): add multi-environment deployment support#71

Draft
aparajon wants to merge 4 commits intomainfrom
multi-env-deploy
Draft

feat(multi-env): add multi-environment deployment support#71
aparajon wants to merge 4 commits intomainfrom
multi-env-deploy

Conversation

@aparajon
Copy link
Copy Markdown
Collaborator

@aparajon aparajon commented May 4, 2026

Summary

Add support for running separate SchemaBot instances per environment (e.g., staging and production on isolated infrastructure). Each instance handles a subset of environments with its own GitHub App and database.

  • allowed_environments config field scopes which environments an instance handles
  • Per-environment aggregate check runs: SchemaBot (staging), SchemaBot (production)
  • Config-driven prior-environment enforcement: owned environments checked via local DB, remote environments checked via GitHub Checks API
  • Environment filtering in webhook handlers — commands for non-allowed environments are silently skipped
  • Fully backwards compatible — single-deployment mode unchanged when allowed_environments is not set
# Staging instance
allowed_environments: [staging]
tern_deployments:
  default:
    staging: "tern-staging:9090"
# Production instance
allowed_environments: [production]
tern_deployments:
  default:
    production: "tern-production:9090"

The production instance enforces "staging before production" by checking GitHub for the SchemaBot (staging) check run from the staging instance — no cross-environment networking needed.

🤖 Generated with Claude Code

Copilot AI review requested due to automatic review settings May 4, 2026 19:11
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds multi-environment deployment support so separate SchemaBot instances can own different environments, publish environment-scoped aggregate checks, and coordinate prior-environment enforcement across instances.

Changes:

  • Added allowed_environments config support and documentation for multi-instance deployments.
  • Filtered webhook command handling and multi-env planning to only process environments owned by the current instance.
  • Added GitHub-check-based prior-environment verification and environment-scoped aggregate check naming/tests.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 6 comments.

Show a summary per file
File Description
pkg/webhook/plan.go Filters multi-environment plan execution to this instance’s allowed environments.
pkg/webhook/issue_comment.go Skips env-targeted commands that belong to another instance.
pkg/webhook/check_runs.go Adds per-environment aggregate names and remote prior-environment checks.
pkg/webhook/check_runs_test.go Adds unit tests for new check-run and environment-filtering helpers.
pkg/github/client.go Adds helper to find a check run by name on a commit.
pkg/api/config.go Introduces allowed_environments config and lookup helper.
pkg/api/config_test.go Tests new config behavior and YAML deserialization.
docs/configuration.md Documents multi-environment deployment setup and behavior.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread pkg/webhook/check_runs.go
Comment thread pkg/webhook/check_runs.go Outdated
Comment thread pkg/webhook/check_runs.go Outdated
Comment thread pkg/webhook/check_runs.go Outdated
Comment thread pkg/webhook/check_runs_test.go Outdated
Comment thread pkg/webhook/check_runs_test.go
Support running separate SchemaBot instances per environment (e.g.,
staging and production on isolated infrastructure). Each instance
handles a subset of environments with its own GitHub App and database.

Key features:
- allowed_environments config scopes which environments an instance handles
- Per-environment aggregate check runs: SchemaBot (staging), SchemaBot (production)
- Config-driven prior-environment enforcement: owned environments checked via
  local DB, remote environments checked via GitHub Checks API (fail-closed)
- respond_to_unscoped config controls which instance responds to help and
  invalid commands (prevents duplicates with multiple GitHub Apps)
- Eyes reaction fires only after routing decisions (avoids duplicate reactions)
- Environment filtering in webhook handlers — non-allowed environments silently skipped

Fully backwards compatible — single-deployment mode unchanged when
allowed_environments is not set.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@aparajon aparajon force-pushed the multi-env-deploy branch from 2c72047 to 6001888 Compare May 5, 2026 17:48
aparajon and others added 3 commits May 5, 2026 15:55
Two self-contained deployments for testing multi-instance SchemaBot:
- deploy/aws-multi-env/staging/ — staging-only instance
- deploy/aws-multi-env/production/ — production-only instance

Each creates its own App Runner, RDS, secrets, and bastion.
Different subnet CIDRs allow same-account deployment.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace duplicated ~800-line main.tf in each environment with a shared
module (~800 lines, one copy) and thin wrappers (~100 lines each).
Move scripts to a shared directory.

Structure:
  modules/schemabot/  — all resources parameterized by environment
  staging/main.tf     — module call with staging vars
  production/main.tf  — module call with production vars
  scripts/            — shared scripts (one copy)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…d scripts

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants