// Standards for pull requests, documentation, and code review in this Terraform provider. Use when creating PRs, writing or editing documentation (schema descriptions, docs markdown, examples), reviewing code, or adding changelog entries. Covers PR structure, docs style guide, example conventions, and changelog practices.
Summarize a GitHub Actions test suite run for the mongodb/terraform-provider-mongodbatlas repo — fetches job logs, classifies failures, and produces a Slack summary led by an explicit code-regression verdict. Use when the user shares a workflow run URL or run_id, or when triggered by the test-suite webhook to decide whether on-call should investigate.
Best practices for writing and organizing acceptance tests in this Terraform provider. Use when creating new acceptance tests, modifying existing tests, fixing flaky tests, or reviewing test code. Covers test consolidation, avoiding duplicates, plural data source ordering, and plan-only validation tests.
Best practices for developing Terraform resources and data sources in this provider. Use when creating new resources, modifying schema definitions, implementing CRUD operations, handling state transitions, or working with autogenerated resources.
| name | pr-and-documentation-standards |
| description | Standards for pull requests, documentation, and code review in this Terraform provider. Use when creating PRs, writing or editing documentation (schema descriptions, docs markdown, examples), reviewing code, or adding changelog entries. Covers PR structure, docs style guide, example conventions, and changelog practices. |
PR titles must follow Conventional Commits: fix:, feat:, chore:, doc:, test:, refactor:, ci:, etc. The subject after the colon must start with an uppercase letter.
fix: Emit warning when use_effective_fields and auto-scaling are enabled
feat: Add search deployment resource
Do not include a scope in parentheses (e.g. fix(resource/mongodbatlas_advanced_cluster): ...). The repo convention uses the bare prefix without a scope.
Avoid mixing refactoring with functional changes in the same PR. Reviewers need to clearly distinguish which changed lines are behavioral vs structural.
Add a changelog entry (.changelog/<PR_NUMBER>.txt) for:
release-note:bug)release-note:enhancement)release-note:breaking-change)release-note:new-resource / release-note:new-data-source)Emits, Adds, Fixes, Updates)Avoid excessive NOTE/IMPORTANT/WARNING boxes. Prefer:
Do not include CLOUDP ticket references in user-facing documentation. Internal ticket references are acceptable in code comments only when tracking a deliberate technical decision.
Start data source and resource descriptions with the resource name and a clear one-line purpose:
`mongodbatlas_log_integration` provides a resource for managing log integration configurations at the project level.
examples/ directory)Do not pin specific provider versions in examples. This avoids examples becoming outdated and ensures users always get the latest compatible version.
All configurable values in examples should use var. references with corresponding entries in variables.tf. Do not hardcode values that users need to customize.
Use a consistent comment for the Atlas project resource block in examples:
# Set up MongoDB Atlas Project access
resource "mongodbatlas_project" "project" {
name = var.atlas_project_name
org_id = var.atlas_org_id
}