Rpothin Terraform Github Res Repository Terraform Workflow

Power Platform Terraform Development Workflow

Development Workflow

Follow these steps when implementing changes to a Power Platform Terraform module:

0. Initialize from Template

1. Choose a module classification based on scope:
   • res-* — Resource module (wraps a single resource type)
   • ptn-* — Pattern module (composes multiple resources)
   • utl-* — Utility module (data lookups and helpers)
2. Replace the placeholder comments in main.tf with actual resource definitions.
3. Update terraform.tf with the correct microsoft/power-platform provider version constraint.
4. Write _header.md describing the module's purpose (used by terraform-docs to generate README.md).
5. Update _footer.md with any additional notes, if needed.
6. Set the registry source in every examples/**/main.tf — strip terraform-powerplatform- from the repo name to get {module-name}, then set source = "rpothin/{module-name}/powerplatform". No version argument. See AGENTS.md for the canonical rule and examples.
7. Run terraform init -backend=false to initialize the working directory.

1. Branch

git checkout -b feat/<short-description>

Use conventional prefixes: feat/, fix/, docs/, ci/, refactor/, test/.

2. Implement

• Add resources in main.tf
• Add input variables in variables.tf with descriptions and validation blocks
• Add outputs in outputs.tf with descriptions
• Add local computations in locals.tf
• Update provider constraints in terraform.tf if needed

Examples Structure

Every module MUST provide two examples:

Each example MUST:

• Have its own _header.md describing the scenario
• Have README.md auto-generated by terraform-docs
• Be referenced in tests/unit/ or tests/integration/ via module { source = "./examples/basic" }
• Use the registry source (derived from the repo name — see AGENTS.md), with no version argument, so consumers always resolve to the latest published version

Example test referencing the basic example:

mock_provider "powerplatform" {}

run "basic_example_plan" {
  command = plan

  module {
    source = "./examples/basic"
  }

  assert {
    condition     = true
    error_message = "Basic example must plan successfully."
  }
}

Correct example source format:

module "this" {
  source = "rpothin/res-environment/powerplatform"

  # ... module inputs
}

3. Format & Validate

terraform fmt -recursive
terraform validate

Optional: If tflint is installed, run tflint --recursive for additional linting beyond terraform validate. Add a .tflint.hcl at the module root to enable the terraform plugin:

plugin "terraform" {
  enabled = true
  preset  = "recommended"
}

Run tflint --init once after creating this file.

4. Test

# Run unit tests (no credentials needed)
terraform test -test-directory=tests/unit

# Run integration tests (requires OIDC credentials)
terraform test -test-directory=tests/integration

5. Generate Documentation

terraform-docs .

Verify that README.md is updated. Never edit README.md manually — it is auto-generated.

6. Security Scan

trivy config .

Trivy uses .trivy.yaml at the repo root for configuration. The template ships a minimal config scoped to the template itself (no real resources). When building a real module from this template, review and adjust .trivy.yaml — see Security Guidance for the full process.

Resolve any HIGH or CRITICAL findings before committing. If a finding is a confirmed false positive for Power Platform resources, suppress it by rule ID in .trivy.yaml with an explanatory comment. Uncommented suppressions will be rejected in code review.

7. Commit & Push

git add .
git commit -m "feat: <concise description>"
git push origin feat/<short-description>

Code Quality Rules

Variables

• Every variable must have a description
• Every variable must have a type
• Use validation blocks for input constraints
• Sensitive values must be marked sensitive = true
• Use nullable = false when null is not a valid input
• Optional inputs SHOULD have a default value; defaults MUST represent the most secure, compliant, and governance-aligned configuration for the attribute — prefer the most restrictive, least-privilege value that still makes the module useful out of the box, minimising the number of required inputs while delivering a strong baseline without extra caller configuration
• Sensitive inputs MUST NOT have a default value (see TFNFR23 in AVM Alignment Guide)

Outputs

• Every output must have a description
• Mark sensitive outputs with sensitive = true
• Output the resource ID and name at minimum

Resources

• Use meaningful resource names that describe purpose
• Always set lifecycle blocks explicitly when needed
• Tag resources using the tags variable pattern
• Never hardcode credentials — use OIDC or environment variables

Naming Conventions

• File names: lowercase with hyphens (main.tf, variables.tf)
• Variable names: lowercase with underscores (environment_id)
• Resource names: lowercase with underscores (powerplatform_environment.this)
• Output names: lowercase with underscores (resource_id)

Provider Conventions

• Pin provider version with pessimistic constraint (~> 4.0)
• Pin Terraform version range: >= 1.9, < 2.0
• Provider configuration belongs in terraform.tf

Power Platform–Specific Conventions

• Use OIDC authentication for CI/CD (no client secrets in pipelines)
• Environment IDs are UUIDs — validate format when accepting as input
• DLP policies may restrict connector usage — document any connector dependencies
• Power Platform resources may have propagation delays — use appropriate timeouts

Tools & MCP Integration

Terraform MCP Server

The Terraform MCP Server allows AI agents to look up live provider schemas from the Terraform Registry at runtime. This is especially valuable for the Power Platform provider, which is not as well-represented in LLM training data as major cloud providers.

Configure the MCP server in your AI tool:

{
  "mcpServers": {
    "terraform": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "TFE_TOKEN", "-e", "TFE_ADDRESS", "hashicorp/terraform-mcp-server"],
      "env": {
        "TFE_TOKEN": "${TFE_TOKEN}",
        "TFE_ADDRESS": "${TFE_ADDRESS}"
      }
    }
  }
}

With this configured, agents can query the exact attributes, types, and descriptions for any microsoft/power-platform resource before writing code — preventing hallucinated resource arguments.

Related Skills

For detailed guidance on specific topics, the agent should load the appropriate skill:

• terraform-style — File organization, naming, formatting, version pinning, provider resource reference
• terraform-testing — .tftest.hcl syntax, mock providers, unit/integration testing patterns
• terraform-avm — AVM specification mapping, compliance checklist
• terraform-security — OIDC authentication, credential handling, DLP, Trivy configuration

Source: rpothin/terraform-github-res-repository — distributed by TomeVault.