Automate Terraform Deployments: (1/2) Detect

This workflow is part of the Terraform-to-Azure deployment automation pipeline.

The primary role is to detect changes to main.tf files in pull requests or direct pushes to the main branch, and then trigger targeted downstream processing for each changed file.

• Architecture
• Grinntec GitHub Repo

---

Purpose

• Change Detection: Identify modifications to any main.tf file.
• Targeted Execution: For each changed file, trigger a reusable downstream workflow to process, test, and deploy changes.
• Efficiency: Avoid running unnecessary jobs when no main.tf changes are detected.
• Modularity: Enable environment-specific or file-specific CI/CD runs.

---

Workflow Jobs

(1) Trigger Condition

Aspect	Description
WHAT	Workflow triggers when main.tf files are modified
HOW	Uses GitHub Actions paths filter: ["**/main.tf"] to monitor any main.tf file changes
WHY	Only runs when Terraform infrastructure code changes, avoiding unnecessary executions
RESULT	Efficient CI/CD that responds specifically to infrastructure changes in push events to main branch or pull requests

on:
  push:
    branches: [main]
    paths: ["**/main.tf"]
  pull_request:
    paths: ["**/main.tf"]

---

(2) Detect Repository Context

Aspect	Description
WHAT	Automatically detects which Azure environment a repository represents based on its name
HOW	Extracts repo name from github.repository and pattern matches: *prod* → PROD, *dev* → DEV, *staging* → STAGING, other → DEFAULT
WHY	Enables one centralized workflow to behave differently per environment without manual configuration
RESULT	Other steps can use the detected environment for environment-specific behavior (notifications, approvals, etc.)

(3) Checkout Repository

Aspect	Description
WHAT	Downloads the repository code so the workflow can analyze which files changed
HOW	Uses actions/checkout@v4 with fetch-depth: 0 for complete git history and ref: ${{ github.ref }} for exact branch/commit
WHY	The workflow must see the git history to detect which main.tf files were modified between commits
RESULT	Workspace is prepared with full repository context for file change detection

(4) Sync to Latest

Aspect	Description
WHAT	Ensures the workspace is synchronized with the latest main branch
HOW	Executes git fetch origin main, git checkout main, git reset --hard origin/main
WHY	Guarantees accurate file change detection by working from the most current main branch state
RESULT	Clean, up-to-date workspace ready for reliable change comparison

(5) Detect Changed main.tf Files

Aspect	Description
WHAT	Identifies which main.tf files have been modified in the current event
HOW	Uses git diff to compare commits (PR: base vs head, Push: previous vs current) and filters for main.tf files, then converts results to JSON array
WHY	Enables targeted processing - only modified infrastructure files trigger downstream workflows
RESULT	JSON array output (changed_main_files) containing paths of all modified main.tf files for matrix processing

(6) Early Exit

Aspect	Description
WHAT	Stops workflow execution if no main.tf files were changed
HOW	Checks if changed_main_files output is empty and exits with notice message
WHY	Saves compute resources and prevents unnecessary downstream processing when no infrastructure changes detected
RESULT	Efficient workflow that only continues when actual Terraform changes require validation

(7) Process Changed main.tf Files

Aspect	Description
WHAT	Executes parallel processing jobs for each changed main.tf file using matrix strategy
HOW	Uses matrix.tfvars_file from JSON array with fail-fast: false, calls reusable workflow process-changed-main-files.yaml for each file
WHY	Enables concurrent validation of multiple infrastructure changes while ensuring isolated processing per file
RESULT	Complete Terraform validation pipeline (format, lint, plan, security scan, cost estimation) runs for each modified file

---

Key Components

Concurrency Control

# Note: Concurrency control is handled by the calling workflow
# to avoid deadlocks between parent and child workflows

• Reusable Workflow Design: This workflow is called by subscription repositories, so concurrency is managed at the caller level
• Prevents Deadlocks: Avoids conflicts between parent (caller) and child (reusable) workflow concurrency groups
• Caller Responsibility: Each subscription repository implements its own concurrency control strategy

Security Considerations

• Principle of Least Privilege: Only required secrets are passed from calling repository to reusable workflow
• Scoped Permissions:

permissions:
  contents: write
  checks: write
  id-token: write

• Secrets Architecture:
  • Repository-specific: AZURE_DEPLOY_TO_MODULE_RO, AZURE_SUBSCRIPTION_ID, AZURE_CLIENT_ID
  • Organization-level: AZURE_TENANT_ID, INFRACOST_API_KEY, SLACK_WEBHOOK_URL
• Secrets Inheritance: Uses secrets: inherit pattern for seamless cross-repository workflow calls

---