Skip to content

Add CD #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
clofour merged 4 commits into from
Apr 19, 2026
Merged

Add CD #6

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
90dcf0b
Add CD
clofour Apr 19, 2026
30ec8dc
Create backend and fix bugs in terraform workflow
clofour Apr 19, 2026
8e77208
Bug fixes
clofour Apr 19, 2026
78b496b
Bugfixes
clofour Apr 19, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 0 additions & 27 deletions .github/workflows/terraform-validate.yaml
View file
Open in desktop

This file was deleted.

57 changes: 57 additions & 0 deletions .github/workflows/terraform.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
name: terraform
on:
push:
branches:
- main
- dev
jobs:
validate:
name: Validate
runs-on: ubuntu-24.04
steps:
- name: Checkout repository
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd

- name: Set up Terraform
uses: hashicorp/setup-terraform@5e8dbf3c6d9deaf4193ca7a8fb23f2ac83bb6c85
with:
terraform_version: "1.14.7"
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot Apr 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

Is Terraform version 1.14.7 a valid release?

💡 Result:

Yes, Terraform version 1.14.7 is a valid official release. It was released on March 11, 2026, as confirmed by multiple authoritative sources including HashiCorp's official release page, GitHub releases, and changelog. Binaries are available at releases.hashicorp.com/terraform/1.14.7/, and it is listed among recent versions on the main releases index. The release notes mention bumping the Go version to 1.25.8 for security scanner fixes. Newer versions like 1.14.8 and 1.15.0 pre-releases exist as of April 2026, but 1.14.7 remains valid and supported.

Citations:

🌐 Web query:

Does Terraform version constraint syntax support the v prefix like "~> v1.14.7"?

💡 Result:

No, Terraform version constraint syntax does not support the 'v' prefix. Version numbers must be a series of numbers separated by periods without a leading 'v', such as "> 1.14.7". Using "> v1.14.7" results in an invalid constraint error, as the 'v' prefix is not part of the expected format.

Citations:

🏁 Script executed:

find . -name "versions.tf" -type f | head -20

Repository: clofour/gitlab-kubernetes

Length of output: 92

🏁 Script executed:

cat -n ./terraform/versions.tf

Repository: clofour/gitlab-kubernetes

Length of output: 799

Fix invalid version constraint syntax in terraform/versions.tf.

Line 2 uses an invalid version constraint with the 'v' prefix: ~> v1.14.7. Terraform version constraints do not support the 'v' prefix. Change it to ~> 1.14.7.


- name: Initialize Terraform project
run: terraform init -backend=false
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot Apr 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick | 🔵 Trivial

Consider configuring remote state backend.

Using local state (the current configuration) in CI/CD is problematic because:

  • State files are not persisted between workflow runs, leading to Terraform treating each run as a fresh deployment
  • No state locking mechanism to prevent concurrent modifications
  • State cannot be shared across team members or other workflows

Consider configuring a remote backend (e.g., S3, Terraform Cloud, or DigitalOcean Spaces) in terraform/versions.tf to persist state and enable state locking.

🧹 Nitpick | 🔵 Trivial

Remove unnecessary -backend=false flag.

The -backend=false flag is unnecessary since terraform/versions.tf does not configure a backend. Terraform will use local state by default without this flag.

♻️ Proposed simplification 
-        run: terraform init -backend=false
+        run: terraform init
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
run: terraform init -backend=false
run: terraform init


- name: Run Terraform Validate
run: terraform validate
deploy:
name: Deploy
runs-on: ubuntu-24.04
environment: production
env:
TF_VAR_do_token: ${{ secrets.DO_TOKEN }}
TF_VAR_do_dns_token: ${{ secrets.DO_DNS_TOKEN }}
TF_VAR_spaces_access_id: ${{ secrets.SPACES_ACCESS_ID }}
TF_VAR_spaces_secret_key: ${{ secrets.SPACES_SECRET_KEY }}
AWS_ACCESS_KEY_ID: ${{ secrets.SPACES_ACCESS_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.SPACES_SECRET_KEY }}
if: github.ref == 'refs/heads/main'
needs: validate
steps:
- name: Checkout repository
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd

- name: Set up Terraform
uses: hashicorp/setup-terraform@5e8dbf3c6d9deaf4193ca7a8fb23f2ac83bb6c85
with:
terraform_version: "1.14.7"

- name: Initialize Terraform project
run: terraform init

- name: Run Terraform Plan
run: terraform plan -out=tfplan

Comment thread
coderabbitai[bot] marked this conversation as resolved.
- name: Run Terraform Apply
run: terraform apply tfplan -auto-approve
defaults:
run:
working-directory: ./terraform
15 changes: 15 additions & 0 deletions terraform/backend.tf
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
terraform {
backend "s3" {
bucket = "gitlab-tfstate-a2ca73"
key = "terraform.tfstate"
region = "us-east-1"
endpoints = {
s3 = "https://fra1.digitaloceanspaces.com"
}

use_lockfile = true
skip_credentials_validation = true
skip_metadata_api_check = true
skip_requesting_account_id = true
}
Comment on lines +2 to +14
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot Apr 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

Terraform S3 backend use_lockfile support and DigitalOcean Spaces S3 conditional writes compatibility

💡 Result:

Terraform S3 backend supports the use_lockfile option for native S3 state locking using a .tflock lockfile and S3 conditional writes (If-None-Match header on PutObject). This feature is opt-in (defaults to false), stable as of Terraform 1.11+, and replaces deprecated DynamoDB locking. Official docs recommend bucket versioning and specific IAM permissions including GetObject/PutObject/DeleteObject on the lockfile. DigitalOcean Spaces is S3-compatible and officially supports using the Terraform S3 backend as a remote state store, explicitly including use_lockfile = true in their documentation examples (updated for Terraform 1.11+). Spaces supports the required S3 conditional writes via If-None-Match (confirmed in Spaces API reference for PutObject and GetObject operations). No known compatibility issues; DigitalOcean recommends standard S3 backend config with custom endpoint, skip validations, and use_lockfile = true for locking. Example config for Spaces: terraform { backend "s3" { endpoints = { s3 = "https://nyc3.digitaloceanspaces.com" } bucket = "your-space" key = "path/to/state.tfstate" region = "us-east-1" skip_credentials_validation = true skip_requesting_account_id = true skip_metadata_api_check = true skip_region_validation = true skip_s3_checksum = true use_lockfile = true } } Note: .terraform.lock.hcl (provider/module lockfile) is local/version-controlled and unrelated to state backend locking.

Citations:

Add state locking to this shared backend.

This backend writes all production deploys to the same terraform.tfstate key with no locking configured. Concurrent deploys will race and corrupt state. DigitalOcean Spaces supports Terraform's use_lockfile option (stable in Terraform 1.11+), which uses S3 conditional writes for native state locking. Add use_lockfile = true to the backend block:

State locking configuration 
 backend "s3" {
     bucket = "gitlab-tfstate-a2ca73"
     key = "terraform.tfstate"
     region = "us-east-1"
     endpoints = {
         s3 = "https://fra1.digitaloceanspaces.com"
     }
 
+    use_lockfile = true
     skip_credentials_validation = true
     skip_metadata_api_check = true
     skip_requesting_account_id = true
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
backend "s3" {
bucket = "gitlab-tfstate-a2ca73"
key = "terraform.tfstate"
region = "us-east-1"
endpoints = {
s3 = "https://fra1.digitaloceanspaces.com"
}
skip_credentials_validation = true
skip_metadata_api_check = true
skip_requesting_account_id = true
}
backend "s3" {
bucket = "gitlab-tfstate-a2ca73"
key = "terraform.tfstate"
region = "us-east-1"
endpoints = {
s3 = "https://fra1.digitaloceanspaces.com"
}
use_lockfile = true
skip_credentials_validation = true
skip_metadata_api_check = true
skip_requesting_account_id = true
}

}