From 1594a01c6fffaf63d77214f0b73b842d96a129c4 Mon Sep 17 00:00:00 2001 From: Simone Ruffilli Date: Fri, 22 May 2026 10:28:01 +0200 Subject: [PATCH] Cosmetic and linter fixes (#3981) --- CONTRIBUTING.md | 2 +- modules/artifact-registry/README.md | 1 - .../data-catalog-policy-tag/schemas/policy-tag.schema.json | 2 +- modules/folder/README.md | 4 ++-- modules/organization/README.md | 2 +- modules/project-factory/schemas/taxonomy.schema.json | 2 +- modules/project/README.md | 2 +- skills/fabric-builder/SKILL.md | 2 +- skills/fabric-builder/references/conventions.md | 4 +--- tests/fast/stages/s0_org_setup/hardened.yaml | 1 - tests/modules/cloudsql_instance/context.tfvars | 1 - 11 files changed, 9 insertions(+), 14 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2040288d9..097284ea6 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -527,7 +527,7 @@ Similarly to our design principles above, we evolved a set of style conventions Over time and as our codebase got larger, we switched away from the canonical `main.tf` naming and now tend to prefer descriptive file names that refer to the logical entities (resources or modules) they contain. -We still use traditional names for variables and outputs, but tend to use main only for top-level locals or resources (e.g. the project resource in the `project` module), or for those resources that would end up in very small files. For smaller modules, a single `variables.tf` and `outputs.tf` is usually enough, however larger modules tend to group variables and outputs in multiple files, for example `variables-iam.tf` in `modules/project`. +We still use traditional names for variables and outputs, but tend to use main only for top-level locals or resources (e.g. the project resource in the `project` module), or for those resources that would end up in very small files. For smaller modules, a single `variables.tf` and `outputs.tf` is usually enough, however larger modules tend to group variables and outputs in multiple files, for example `variables-iam.tf` in `modules/project`. While some older modules and examples are still using three files, we are slowly bringing all code up to date and any new development should use descriptive file names. diff --git a/modules/artifact-registry/README.md b/modules/artifact-registry/README.md index 3bf72faf5..1dad8bb1f 100644 --- a/modules/artifact-registry/README.md +++ b/modules/artifact-registry/README.md @@ -419,4 +419,3 @@ module "legacy_custom_repo" { } # tftest modules=1 resources=1 inventory=legacy-custom.yaml ``` - diff --git a/modules/data-catalog-policy-tag/schemas/policy-tag.schema.json b/modules/data-catalog-policy-tag/schemas/policy-tag.schema.json index 23da50da8..ae15b1971 100644 --- a/modules/data-catalog-policy-tag/schemas/policy-tag.schema.json +++ b/modules/data-catalog-policy-tag/schemas/policy-tag.schema.json @@ -150,4 +150,4 @@ } } } -} \ No newline at end of file +} diff --git a/modules/folder/README.md b/modules/folder/README.md index 779b32f62..1a9f2a3ce 100644 --- a/modules/folder/README.md +++ b/modules/folder/README.md @@ -729,11 +729,11 @@ module "folder" { ## IAM Deny Policies -[IAM Deny policies](https://cloud.google.com/iam/docs/deny-overview) allow you to set centralized guardrails that prevent principals from using specific permissions within the folder and all of its descendants, regardless of the roles they have been granted. +[IAM Deny policies](https://cloud.google.com/iam/docs/deny-overview) allow you to set centralized guardrails that prevent principals from using specific permissions within the folder and all of its descendants, regardless of the roles they have been granted. You can define Deny policies using the `iam_deny_policies` variable. Each policy requires you to specify the principals and permissions to deny. You can optionally define exception principals, exception permissions, and conditions to tailor the restriction. -Note that IAM Deny policies require a specific prefix for principal definitions (e.g., `principalSet://goog/public:all` or `principalSet://goog/group/group-email@example.com`), and permissions must be prefixed with the service fully qualified domain name (e.g., `iam.googleapis.com/serviceAccountKeys.create`). +Note that IAM Deny policies require a specific prefix for principal definitions (e.g., `principalSet://goog/public:all` or `principalSet://goog/group/group-email@example.com`), and permissions must be prefixed with the service fully qualified domain name (e.g., `iam.googleapis.com/serviceAccountKeys.create`). ```hcl module "folder" { diff --git a/modules/organization/README.md b/modules/organization/README.md index c792a612b..206231916 100644 --- a/modules/organization/README.md +++ b/modules/organization/README.md @@ -1013,7 +1013,7 @@ module "org" { ## IAM Deny Policies -[IAM Deny policies](https://cloud.google.com/iam/docs/deny-overview) allow you to set centralized guardrails that prevent principals from using specific permissions, regardless of the roles they have been granted. +[IAM Deny policies](https://cloud.google.com/iam/docs/deny-overview) allow you to set centralized guardrails that prevent principals from using specific permissions, regardless of the roles they have been granted. You can define Deny policies using the `iam_deny_policies` variable. Each policy requires you to specify the principals and permissions to deny, and optionally allows you to define exception principals, exception permissions, and conditions. diff --git a/modules/project-factory/schemas/taxonomy.schema.json b/modules/project-factory/schemas/taxonomy.schema.json index 23da50da8..ae15b1971 100644 --- a/modules/project-factory/schemas/taxonomy.schema.json +++ b/modules/project-factory/schemas/taxonomy.schema.json @@ -150,4 +150,4 @@ } } } -} \ No newline at end of file +} diff --git a/modules/project/README.md b/modules/project/README.md index 3e4317f99..c9ff26375 100644 --- a/modules/project/README.md +++ b/modules/project/README.md @@ -2248,7 +2248,7 @@ module "project" { ## IAM Deny Policies -[IAM Deny policies](https://cloud.google.com/iam/docs/deny-overview) allow you to set centralized guardrails that prevent principals from using specific permissions within the project, regardless of the roles they have been granted. +[IAM Deny policies](https://cloud.google.com/iam/docs/deny-overview) allow you to set centralized guardrails that prevent principals from using specific permissions within the project, regardless of the roles they have been granted. You can define Deny policies using the `iam_deny_policies` variable. Each policy requires you to specify the principals and permissions to deny. You can optionally define exception principals, exception permissions, and conditions to tailor the restriction. diff --git a/skills/fabric-builder/SKILL.md b/skills/fabric-builder/SKILL.md index 8f89ce7ad..21bf3ce28 100644 --- a/skills/fabric-builder/SKILL.md +++ b/skills/fabric-builder/SKILL.md @@ -27,7 +27,7 @@ This skill generates idiomatic Terraform code using Cloud Foundation Fabric (CFF ## Guidelines for Output - **Root Module Output:** Your output must be a complete Terraform root module that calls the appropriate CFF modules to fulfill the user's requirements. -- **Use Fabric Modules:** Rely on CFF modules instead of raw `google_` resources whenever possible. +- **Use Fabric Modules:** Rely on CFF modules instead of raw `google_` resources whenever possible. - **Example-based Learning:** Always refer to the module's README (fetched via `scripts/fabric.py`) for correct usage examples. - **Module Source:** When generating module calls, use a GitHub source. It should look like this: `source = "github.com/GoogleCloudPlatform/cloud-foundation-fabric//modules/project?ref={VERSION}&depth=1"`. - **Formatting & Validation:** Ensure the generated code is properly formatted. If possible, run `terraform fmt`, `terraform validate`, and `terraform plan` to check your work. diff --git a/skills/fabric-builder/references/conventions.md b/skills/fabric-builder/references/conventions.md index ee4453442..799765fcd 100644 --- a/skills/fabric-builder/references/conventions.md +++ b/skills/fabric-builder/references/conventions.md @@ -29,7 +29,7 @@ When generating Terraform code that consumes Cloud Foundation Fabric modules, yo ## 5. Style for Root Modules - **File Structure:** Make file structure dependent on size. For small configurations, use a single `main.tf`. For larger configurations, split into multiple files grouped by resource type (e.g., `main.tf` for general elements, `networking.tf`, `compute.tf`, etc.). -- **Variables & Defaults:** +- **Variables & Defaults:** - Define all variables in `variables.tf`, sorted alphabetically. - Set defaults directly in the `default` attribute if a reasonable default exists or if provided by the user. - Avoid creating a `terraform.tfvars` file unless explicitly requested by the user. @@ -60,5 +60,3 @@ provider "google-beta" { impersonate_service_account = "${service_account}" } ``` - - diff --git a/tests/fast/stages/s0_org_setup/hardened.yaml b/tests/fast/stages/s0_org_setup/hardened.yaml index 5a35eb5c8..335654ee9 100644 --- a/tests/fast/stages/s0_org_setup/hardened.yaml +++ b/tests/fast/stages/s0_org_setup/hardened.yaml @@ -8433,4 +8433,3 @@ outputs: subnet_self_links: {} tfvars: __missing__ vpc_self_links: {} - diff --git a/tests/modules/cloudsql_instance/context.tfvars b/tests/modules/cloudsql_instance/context.tfvars index fb6bd14a2..b0b115231 100644 --- a/tests/modules/cloudsql_instance/context.tfvars +++ b/tests/modules/cloudsql_instance/context.tfvars @@ -27,4 +27,3 @@ insights_config = { query_plans_per_minute = 10 enhanced_query_insights_enabled = true } -