Skip to main content
The copilot can search files, read source code, trace change history, and look up infrastructure-as-code definitions across your connected GitHub and GitLab repositories. Use it to find where things are configured, who changed what, and how infrastructure definitions map to running resources.

​
Prerequisites

GitHub

Connect GitHub to search repositories, read files, and query PR history.

GitLab

Connect GitLab to search repositories, read files, and query MR history.
Code investigation queries don’t require the @ targeting syntax. The copilot searches across all connected repositories automatically. Mention a specific repository name in your query to narrow the search.

​
File Search and Reading

Find and read files across your connected repositories.
Search for specific functions, configurations, patterns, and definitions across repositories.

​
Change History

Query recent PRs, commits, blame information, and diffs to understand what changed and why.

​
Infrastructure-as-Code Lookup

Find and read Terraform, Helm, CloudFormation, and Pulumi definitions that manage your running infrastructure.
Search across multiple repositories to trace configurations and dependencies.

​
Example Conversation

You:
The payments-api is failing with connection refused errors when trying to reach the orders database. Can you find how the database host is configured?
Kestrel:
I searched across your connected repositories and found the database configuration in two places:
  1. Application code — acme/payments-service/src/config/database.ts reads the ORDERS_DB_HOST environment variable, falling back to localhost:5432 if unset.
  2. Kubernetes manifest — acme/infrastructure/k8s/payments/deployment.yaml sets ORDERS_DB_HOST to orders-db.payments.svc.cluster.local:5432 via a ConfigMap reference (payments-db-config).
The ConfigMap payments-db-config is defined in acme/infrastructure/k8s/payments/configmap.yaml. The current value on the main branch is orders-db.payments.svc.cluster.local:5432.
You:
Was this ConfigMap changed recently?
Kestrel:
Yes. PR #312 in acme/infrastructure was merged 3 hours ago by @alex.kim. The PR changed the ORDERS_DB_HOST value from orders-db.payments.svc.cluster.local:5432 to orders-db-v2.payments.svc.cluster.local:5432 as part of a database migration. The PR description mentions: “Point payments-api to the new PostgreSQL 16 instance.” However, I don’t see a corresponding Kubernetes Service named orders-db-v2 in the payments namespace — the service may not have been created yet, which would explain the connection refused errors.
You:
Show me the Terraform code for the new database instance. Is it fully provisioned?
Kestrel:
The new RDS instance is defined in acme/infrastructure/terraform/modules/rds/orders-db-v2.tf. It was added in PR #308, merged last week. The Terraform config provisions a db.r6g.large PostgreSQL 16.2 instance in us-east-1a with Multi-AZ enabled. The Terraform output orders_db_v2_endpoint is referenced in the Kubernetes Service definition in acme/infrastructure/k8s/payments/service-orders-db-v2.yaml — but this file was added in PR #313, which is still open and hasn’t been merged yet. That’s why the Service doesn’t exist in the cluster.

​
Next Steps