Issue:
- Cache steps were timing out after ~5 minutes with ETIMEDOUT errors
- Gitea Actions cache server not configured or not responding
- Connection attempts to 172.19.0.3:36175 failing
- Added 8-10 minutes of unnecessary delays to pipeline
Solution:
- Removed 'Cache Terraform Providers' step from terraform-init job
- Removed 'Restore Terraform Cache' step from terraform-apply job
- Terraform init will download providers fresh each time
- No performance degradation since cache was never working
Impact:
- Faster pipeline execution (removes timeout delays)
- No functional changes (cache was never successful)
- Apply job still independent and self-contained
Note: terraform-vsphere-network never had cache steps (copied before caching was added)
Optimizations:
- Added Terraform provider caching to terraform-init job
- Apply job now reuses cached .terraform directory
- Cache persists across workflow runs (keyed by .terraform.lock.hcl)
- Significantly faster init times on subsequent runs
New terraform-destroy job:
- Only triggered on pull requests with 'destroy' label
- Requires manual approval via 'destroy-approval' environment
- Self-contained with fresh init (no cache for safety)
- Clear warnings and authorization verification
- Three-step process: verify → plan → execute
Security features:
- Destroy only runs on labeled pull requests
- Requires environment protection approval
- Fresh terraform init without cache for verification
- Detailed logging of who/what/when/where
- Cannot be triggered on direct push to master
Usage:
1. Create pull request with proposed destroy changes
2. Add 'destroy' label to the PR
3. Approve via Gitea environment protection
4. Review destroy plan in logs
5. Approve destroy-approval environment to execute
Benefits:
- Faster apply workflow (cached providers)
- Safe destroy process with multiple safeguards
- Clear audit trail for destructive operations
- Self-contained destroy for maximum safety
- New terraform-apply job runs after terraform-init
- Requires manual approval via production environment gate
- Only runs on push to master branch
- Downloads plan file from MinIO
- Applies the exact plan that was reviewed
- Includes all necessary environment variables for Vault and vSphere
- Removed actions/upload-artifact@v4 (not supported in Gitea)
- Added terraform show output to create human-readable plan text
- Upload both binary plan and text version to MinIO
- Plan stored at: s3://bucket/terraform-plans/repo/run-number/
- Uses existing AWS CLI with S3-compatible endpoint
- Added terraform plan step that outputs plan to tfplan file
- Plan includes all required environment variables for Vault and MinIO
- Plan artifact uploaded with 30-day retention for later apply step
- Plan file can be downloaded and used for terraform apply
- Updated backend.tf to use partial configuration
- Modified workflow to pass backend settings via -backend-config flags
- Follows Azure-style pattern with environment variables
- Improves flexibility and keeps configuration out of version control
- Required secrets: MINIO_ENDPOINT, MINIO_BUCKET, MINIO_STATE_KEY
- Added TFLint job to catch Terraform errors and best practices
- TFLint runs before Checkov for early error detection
- Uses latest TFLint version with automatic initialization
- Pipeline flow: TFLint -> Checkov -> SonarQube
- Added Checkov security scan job that runs before SonarQube
- Configured for Terraform-specific IaC compliance checks
- Outputs results in CLI and SARIF formats
- Uploads scan results as artifacts for review
- SonarQube job now depends on Checkov passing
- Renamed workflow to reflect both quality and security scanning
- Updated SonarQube action from kitabisa/sonarqube-action@v1.2.0 to sonarsource/sonarqube-scan-action@v4
- Official action uses Java 17, compatible with SonarQube 25.10
- Added sonar-project.properties with Terraform-specific exclusions
- Fixes: java.lang.UnsupportedClassVersionError (class file version 61.0 vs 55.0)
