Introducción a Cloud Foundation Toolkit

1. Introducción a CFT 101

Última actualización: 11/02/2022

¿Qué es Cloud Foundation Toolkit?

En esencia, CFT proporciona plantillas de prácticas recomendadas para comenzar rápidamente en Google Cloud Platform. En este instructivo, aprenderás a contribuir a Cloud Foundation Toolkit.

Requisitos

• Una cuenta de GitHub
• Docker instalado en tu máquina o Cloud Shell ( instalación en Mac, instalación en Windows)
• Editor de código para editar código (ejemplo: Visual Studio Code)
• Conocimientos básicos de Git y GitHub
• Algo de experiencia con Terraform y la infraestructura como código
• Permiso para otorgar el rol de creador del proyecto a una cuenta de servicio
• Una organización de Google Cloud, una carpeta de prueba y una cuenta de facturación

Qué compilarás

En este codelab, aprenderás a contribuir con Cloud Foundation Toolkit (CFT).

Harás lo siguiente:

• Configura un entorno de desarrollo para contribuir con CFT
• Cómo agregar una función a un módulo de CFT
• Agrega pruebas para la función agregada
• Ejecuta pruebas de integración en CFT
• Ejecuta pruebas de lint
• Confirma el código en GitHub y envía una solicitud de extracción (PR)

Ejecutarás todos los pasos anteriores agregando una nueva función al módulo de CFT de Google Cloud Storage. Agregarás una etiqueta llamada "silly_label", que se agregará automáticamente a todos los buckets creados a través del módulo de CFT de GCS. También escribirás pruebas para validar tu función y garantizar la integración de extremo a extremo.

2. Configura el entorno de desarrollo

Si lo deseas, puedes usar Cloud Shell para tus fines de desarrollo. Si no quieres usar Cloud Shell para contribuir a CFT, puedes configurar tu entorno de desarrollo en tu máquina.

Configura Git

GitHub se basa en un sistema de control de versiones (VCS) de código abierto llamado Git. Git es responsable de todo lo relacionado con GitHub que sucede de forma local en tu máquina o en Cloud Shell.

1. Cuando usas Cloud Shell, no necesitas instalar Git, ya que viene preinstalado.

$ git --version
# This will display the git version on the Cloud Shell.

Si vas a configurar tu entorno de desarrollo en tu máquina, debes instalar Git.

Descarga e instala la versión más reciente de Git

Cómo configurar tu nombre de usuario y correo electrónico en Git

Git usa un nombre de usuario para asociar las confirmaciones con una identidad. El nombre de usuario de Git no es el mismo que el nombre de usuario de GitHub.

Puedes cambiar el nombre asociado a tus confirmaciones de Git con el comando git config. Cambiar el nombre asociado a tus confirmaciones de Git con git config solo afectará a las confirmaciones futuras y no cambiará el nombre que se usó para las confirmaciones anteriores.

Cómo configurar tu nombre de usuario de Git para cada repositorio en tu computadora

En Mac o Linux, abre una terminal.

En Windows, abre Git Bash.

Configura un nombre de usuario de Git:

$ git config --global user.name "Your Name"

$ git config --global user.email "[e-mail]"

Confirma que configuraste el nombre de usuario de Git correctamente:

$ git config --list

> Your Name

> Your Email

Configuraste Git correctamente y deberías poder bifurcar, crear y clonar ramas. Usaremos Git de forma extensiva en este codelab.

3. Bifurca el repositorio de GCS de CFT

Bifurca un repositorio de CFT

En el paso anterior, configuraste Git en tu máquina local o en Cloud Shell. Ahora debes bifurcar el repo de CFT de Google Cloud Storage para comenzar a contribuir.

Una bifurcación es una copia de un repositorio. La bifurcación de un repositorio te permite experimentar libremente con los cambios sin afectar el proyecto original.

Por lo general, las bifurcaciones se usan para proponer cambios en el proyecto de otra persona o para usar el proyecto de otra persona como punto de partida para tu propia idea.

Por ejemplo, puedes usar bifurcaciones para proponer cambios relacionados con la corrección de un error. Para corregir un error, puedes hacer lo siguiente:

• Bifurca el repositorio.
• Realiza la corrección.
• Envía una solicitud de extracción al propietario del proyecto.

Pasos para bifurcar un repo de CFT:

1. Abre tu navegador web y navega al repositorio terraform-google-modules/terraform-google-cloud-storage. Usaremos este repo durante todo el codelab.
2. En la esquina superior derecha de la página, haz clic en Bifurcar (Fork).

3. Aparecerá una opción para elegir dónde quieres tener la bifurcación. Elige tu perfil y se bifurcará el repo.

Clona tu bifurcación de forma local

La bifurcación que creaste es una copia del repositorio del módulo de GCS. Ahora clonarás este repositorio en tu entorno local para agregar la nueva función.

Sigue estos pasos para clonar tu bifurcación:

1. Abre tu navegador web y navega a tu bifurcación en terraform-google-modules/terraform-google-cloud-storage.
2. En la esquina superior derecha, encontrarás el botón "Código". Haz clic en él.

3. Después de hacer clic en el botón "Código", haz clic en el ícono "Copiar" para copiar la URL de la bifurcación. Usarás esta URL para clonar tu bifurcación en tu entorno local.

4. Ve a una terminal en VSCode o en tu máquina y clona la bifurcación.

$ git clone <url>
# This command will clone your fork locally.
# Paste the copied URL from the previous step.

5. Ahora que clonaste tu bifurcación de forma local, debes ir a tu repo, crear una rama nueva a partir de la bifurcación y realizar cambios de código en la rama temporal.

Por convención, puedes nombrar tu rama de la siguiente manera:

• Para solicitudes de funciones: feature/feature-name
• En el caso de las actualizaciones internas, internal/change-name
• Para correcciones de errores: bugfix/issue-name

Como agregarás una nueva función, puedes llamar a tu rama temporal feature/silly_label.

$ cd terraform-google-cloud-storage
# This command takes you into the cloned directory on your local machine.

$ git branch
# This command tells your current branch
# When you run this for the first time after you have cloned, your 
# output should say "master", that is your fork.

$ git checkout -b feature/silly_label
# This command creates a new branch on your fork and switches your 
# branch to the newly created branch.

$ git branch
# This command will confirm your current branch to be "feature/silly_label"

Ya está todo listo para comenzar a trabajar en Cloud Foundation Toolkit.

4. Crea un entorno de prueba

El proceso de desarrollo estándar de CFT se basa en el uso de un proyecto de prueba aislado para las pruebas. En este paso, se te guiará para crear el proyecto de prueba (basado en una configuración estándar) a través de una cuenta de servicio.

0. Instala Docker Engine

Si usas tu máquina para fines de desarrollo, debes instalar Docker Engine.

Nota: Si usas Cloud Shell, no es necesario que instales Docker, ya que Cloud Shell ya lo tiene.

1. Instala el SDK de Google Cloud

No es necesario que instales el SDK de Google Cloud si usas Cloud Shell de GCP.

Ve a Google Cloud SDK y descarga el instalador interactivo para tu plataforma.

2. Establecer configuración

Para crear un entorno de prueba, necesitarás una organización de Google Cloud, una carpeta de prueba y una cuenta de facturación. Estos valores deben establecerse a través de variables de entorno:

export TF_VAR_org_id="your_org_id"
export TF_VAR_folder_id="your_folder_id"
export TF_VAR_billing_account="your_billing_account_id"

3. Configura tu cuenta de servicio

Antes de crear un entorno de prueba, debes descargar una clave de cuenta de servicio en él. Esta cuenta de servicio necesitará los roles de Creador de proyectos, Usuario de cuenta de facturación y Visualizador de la organización. Estos pasos te ayudan a crear una cuenta de servicio nueva, pero también puedes volver a usar una cuenta existente.

3.1 Crea o selecciona un proyecto de GCP inicial

Antes de crear tu cuenta de servicio, debes seleccionar un proyecto en el que alojarla. También puedes crear un proyecto nuevo.

gcloud config set core/project YOUR_PROJECT_ID

3.2 Habilita las APIs de Google Cloud

Habilita las siguientes APIs de Google Cloud en tu proyecto inicial:

gcloud services enable cloudresourcemanager.googleapis.com
gcloud services enable iam.googleapis.com
gcloud services enable cloudbilling.googleapis.com

3.3 Crea una cuenta de servicio

Crea una cuenta de servicio nueva para administrar el entorno de pruebas:

# Creating a service account for CFT.
gcloud iam service-accounts create cft-onboarding \
  --description="CFT Onboarding Terraform Service Account" \
  --display-name="CFT Onboarding"

# Assign SERVICE_ACCOUNT environment variable for later steps
export SERVICE_ACCOUNT=cft-onboarding@$(gcloud config get-value core/project).iam.gserviceaccount.com

Verifica que se haya creado tu cuenta de servicio:

gcloud iam service-accounts list --filter="EMAIL=${SERVICE_ACCOUNT}"

3.4 Otorga los roles de Creador del proyecto, Usuario de la cuenta de facturación y Visualizador de la organización a la cuenta de servicio:

gcloud resource-manager folders add-iam-policy-binding ${TF_VAR_folder_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.projectCreator"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud beta billing accounts add-iam-policy-binding ${TF_VAR_billing_account} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.organizationViewer"

Ahora tienes una cuenta de servicio que se puede usar para administrar el entorno de pruebas.

4. Prepara las credenciales de Terraform

Para crear el entorno de prueba, debes descargar la clave de la cuenta de servicio en tu shell.

4.1 Clave de cuenta de servicio

Crea y descarga una clave de cuenta de servicio para Terraform

gcloud iam service-accounts keys create cft.json --iam-account=${SERVICE_ACCOUNT}

4.2 Configura las credenciales de Terraform

Suminístrale la clave a Terraform con la variable de entorno SERVICE_ACCOUNT_JSON y establece el valor en el contenido de la clave de tu cuenta de servicio.

export SERVICE_ACCOUNT_JSON=$(< cft.json)

Después de almacenar la información de las credenciales en la variable de entorno, quita el archivo de claves. Puedes volver a crear una clave más adelante si es necesario con el mismo comando anterior.

rm -rf cft.json

5. Crea un proyecto de prueba para las implementaciones de Terraform

Ahora que todo está preparado, puedes crear el proyecto de prueba con un solo comando. Ejecuta este comando desde la raíz del directorio terraform-google-cloud-storage:

make docker_test_prepare

Verás el siguiente resultado cuando ejecutes make docker_test_prepare. Al final, recibirás el ID del proyecto de prueba que se creó, en el que implementarás y probarás tu módulo de Cloud Storage con tu nueva función. Si tienes problemas para vincular una cuenta de facturación, consulta los pasos para solucionar problemas.

macbookpro3:terraform-google-cloud-storage user$ make docker_test_prepare
docker run --rm -it \
                -e SERVICE_ACCOUNT_JSON \
                -e TF_VAR_org_id \
                -e TF_VAR_folder_id \
                -e TF_VAR_billing_account \
                -v /Users/cft/terraform-google-cloud-storage:/workspace \
                gcr.io/cloud-foundation-cicd/cft/developer-tools:0.8.0 \
                /usr/local/bin/execute_with_credentials.sh prepare_environment
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Initializing modules...

Initializing the backend...

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.google-beta: version = "~> 3.9"
* provider.null: version = "~> 2.1"
* provider.random: version = "~> 2.2"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
module.project.module.project-factory.null_resource.preconditions: Refreshing state... [id=8723188031607443970]
module.project.module.project-factory.null_resource.shared_vpc_subnet_invalid_name[0]: Refreshing state... [id=5109975723938185892]
module.project.module.gsuite_group.data.google_organization.org[0]: Refreshing state...
module.project.module.project-factory.random_id.random_project_id_suffix: Refreshing state... [id=rnk]
module.project.module.project-factory.google_project.main: Refreshing state... [id=<project-id>]
module.project.module.project-factory.google_project_service.project_services[0]: Refreshing state... [id=<project-id>/storage-api.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[1]: Refreshing state... [id=<project-id>/cloudresourcemanager.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[2]: Refreshing state... [id=<project-id>/compute.googleapis.com]
module.project.module.project-factory.data.null_data_source.default_service_account: Refreshing state...
module.project.module.project-factory.google_service_account.default_service_account: Refreshing state... [id=projects/ci-cloud-storage-ae79/serviceAccounts/project-service-account@<project-id>.iam.gserv
iceaccount.com]
module.project.module.project-factory.google_project_service.project_services[3]: Refreshing state... [id=<project-id>/serviceusage.googleapis.com]
module.project.module.project-factory.null_resource.delete_default_compute_service_account[0]: Refreshing state... [id=3576396874950891283]
google_service_account.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_service_account_key.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com/keys/351009a1e011e88049ab2097994d1c627a61
6961]
google_project_iam_member.int_test[1]: Refreshing state... [id=<project-id>/roles/iam.serviceAccountUser/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_project_iam_member.int_test[0]: Refreshing state... [id=<project-id>/roles/storage.admin/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

project_id = <test-project-id>
sa_key = <sensitive>
Found test/setup/make_source.sh. Using it for additional explicit environment configuration.

Ahora creaste un proyecto de prueba al que se hace referencia con project_id, como puedes ver en el resultado de la consola. Ya configuraste tu entorno de desarrollo y pruebas.

5. Agrega una nueva función al módulo de CFT

Ahora que configuraste tu entorno de desarrollo y pruebas, comencemos a agregar la función "silly_label" al módulo CFT de google-cloud-storage.

Asegúrate de estar en terraform-google-cloud-storage y abre el archivo main.tf como se muestra a continuación en la estructura de carpetas.

Dado que "silly_label" es una etiqueta, agregarás la función en la línea 27 en la variable "labels" en main.tf, como se muestra a continuación:

terraform-google-cloud-storage/main.tf

resource "google_storage_bucket" "buckets" {
 <...>
 storage_class = var.storage_class
 // CODELAB:Add silly label in labels variable
 labels        = merge(var.labels, { name = replace("${local.prefix}${lower(each.value)}", ".", "-") }, { "silly" = var.silly_label })
 force_destroy = lookup(
 <...>
}

Ahora, agregarás la variable silly_label en el archivo variables.tf que ves en la estructura de carpetas anterior.

Copia y pega el siguiente código, agrégalo a la línea 31 en variables.tf y asegúrate de tener un carácter de nueva línea arriba y abajo del bloque de variables que agregues.

terraform-google-cloud-storage/variables.tf

variable "names" {
 description = "Bucket name suffixes."
 type        = list(string)
}

// CODELAB: Add "silly_label" variable to variables.tf between "names" and "location"
variable "silly_label" {
 description = "Sample label for bucket."
 type        = string
}

variable "location" {
 description = "Bucket location."
 default     = "EU"
}

6. Agrega una nueva función al ejemplo de bucket de almacenamiento

Agregaste tu función al archivo main.tf del módulo y ahora la probarás con un ejemplo.

La "silly_label" deberá agregarse a examples/multiple-buckets/main.tf

Este ejemplo se usará en el siguiente paso para realizar pruebas de integración.

Copia y pega la siguiente línea de la variable silly_label en la línea 27 de main.tf en terraform-google-cloud-storage/examples/multiple-buckets/, como se ve en la estructura de carpetas:

terraform-google-cloud-storage/examples/multiple-buckets/main.tf

module "cloud_storage" {
 <...>
 // CODELAB: Add "silly_label" as an example to main.tf.
 silly_label        = "awesome"

 <..>
}

7. Actualiza la prueba del esquema para verificar la función

Agregaste tu función a main.tf del módulo y, luego, la agregaste al ejemplo de multiple_buckets. Ahora, debes probar tu función a través de una prueba de integración de blueprint escrita en Golang.

Agregarás tus pruebas nuevas en el archivo multiple_buckets_test.go que se encuentra en la siguiente estructura de carpetas:

Agregaste la etiqueta "silly_label" en todos los buckets que se crean a través del módulo multiple_buckets y ahora debes escribir pruebas para probar la nueva función.

En el siguiente código, obtienes la etiqueta de cada bucket a través del comando gcloud alpha storage y, luego, verificas el resultado que devolvió el comando.

test/integration/multiple_buckets/multiple_buckets_test.go

func TestMultipleBuckets(t *testing.T) {
 <..>
op := gcloud.Run(t, fmt.Sprintf("alpha storage ls --buckets gs://%s", bucketName), gcloudArgs).Array()[0]

// verify silly label on each bucket
assert.Equal("awesome", op.Get("metadata.labels.silly").String(), "should have silly label set to awesome")

// verify lifecycle rules
...
}

8. Ejecuta pruebas de integración en CFT

Pruebas de integración

Las pruebas de integración se usan para verificar el comportamiento del módulo raíz, los submódulos y los ejemplos. Las adiciones, los cambios y las correcciones deben incluir pruebas.

Las pruebas de integración se escriben con el framework de pruebas de Blueprint y se ejecutan con la CLI de CFT. Para mayor comodidad, estas herramientas se empaquetan en una imagen de Docker.

La estrategia general para estas pruebas es verificar el comportamiento de los módulos de ejemplo y, de este modo, garantizar que el módulo raíz, los submódulos y los módulos de ejemplo sean todos correctos desde el punto de vista funcional.

En la ejecución interactiva, ejecutas cada paso a través de varios comandos.

1. Ejecuta make docker_run para iniciar el contenedor de Docker de prueba en modo interactivo.

Make es una herramienta de automatización de compilaciones que compila automáticamente programas y bibliotecas ejecutables a partir del código fuente leyendo archivos llamados Makefiles, que especifican cómo derivar el programa objetivo. Cuando realices cambios en los archivos, el contenedor de Docker se debe actualizar automáticamente.

Cuando ejecutas make docker_run, creas un espacio de trabajo en tu contenedor de Docker y activas las credenciales de tu cuenta de servicio. El espacio de trabajo se usará en los próximos pasos para ejecutar pruebas.

Verás el siguiente resultado en tu terminal:

Activated service account credentials for: [cft@<PROJECT_ID>.iam.gserviceaccount.com]

2. Ejecuta module-swapper -registry-prefix=terraform-google-modules ​para ajustar los archivos de ejemplo main.tf y, así, importar los módulos desde tus archivos locales en lugar de los módulos publicados.

Deberías ver un resultado como el siguiente en tu terminal:

[root@<CONTAINER_ID> workspace]# module-swapper -registry-prefix=terraform-google-modules
2025/08/04 19:26:29 Module name set from remote to cloud-storage
2025/08/04 19:26:29 Modifications made to file /workspace/examples/multiple_buckets/main.tf
2025/08/04 19:26:29 --- Original
+++ Modified
@@ -21,7 +21,7 @@
 }
 
 module "cloud_storage" {
-  source = "terraform-google-modules/cloud-storage/google"
+  source = "../.."
   # [restore-marker]   version = "~> 10.0"
 
   project_id = var.project_id

3. Ejecuta cft test list para enumerar todas las pruebas de planos en tu espacio de trabajo.

Verás el siguiente resultado en tu terminal:

[root@CONTAINER_ID workspace]# cft test list
 NAME                           | CONFIG                    | LOCATION                                                   
--------------------------------+---------------------------+------------------------------------------------------------
 TestAll/examples/simple_bucket | examples/simple_bucket    | test/integration/discover_test.go                          
 TestMultipleBuckets            | examples/multiple_buckets | test/integration/multiple_buckets/multiple_buckets_test.go 

4. Ejecuta cft test run <EXAMPLE_NAME> --stage init para inicializar el ejemplo. En este caso, para inicializar la ejecución de prueba de TestMultipleBuckets, cft test run TestMultipleBuckets --stage init. También puedes usar la marca --verbose para obtener información adicional cuando ejecutas pruebas.

Esta etapa de inicialización inicializa el ejemplo de Terraform.

Verás el siguiente resultado en tu terminal.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage init --verbose
INFO[02-09|08:24:31] using test-dir: test/integration 
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:179: Terraform has been successfully initialized!
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:100: Running command terraform with args [validate]
TestMultipleBuckets 2022-02-09T08:24:36Z command.go:179: Success! The configuration is valid.
...
--- PASS: TestMultipleBuckets (4.05s)

Nota: Es posible que veas advertencias como Skipping fixtures discovery en los registros. Estas son advertencias para la depuración y se pueden ignorar. Si se producen errores, la prueba fallará.

5. Ejecuta cft test run <EXAMPLE_NAME> --stage apply para aplicar el módulo de ejemplo.

En este paso, se aplica el ejemplo inicializado en la etapa anterior al proyecto de GCP que se creó anteriormente en el codelab.

Verás el siguiente resultado en tu terminal.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage apply --verbose
INFO[02-09|08:28:11] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Apply complete! Resources: 6 added, 0 changed, 0 destroyed.
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Outputs:
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: names = {
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179:   "one" = "multiple-buckets-erp1-eu-one"
...
--- PASS: TestMultipleBuckets (6.51s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.548s

Nota: Si ves Request violates constraint 'constraints/storage.uniformBucketLevelAccess' en los registros, es porque tu proyecto no puede establecer uniform_bucket_level_access como falso. Para este codelab, puedes solucionar este problema configurando cloud_storage.bucket_policy_only["two"] en true en lugar de false y cambiando la prueba de Golang según corresponda.

6. Ejecuta cft test run <EXAMPLE_NAME> --stage verify para verificar que el ejemplo haya creado la infraestructura esperada.

En este paso, se ejecutará la función de verificación en TestMultipleBuckets. Por lo general, la verificación se realiza ejecutando un comando de gcloud para recuperar la salida JSON del estado actual de un recurso y confirmar que el estado actual es el que se declaró en el ejemplo.

Si recibes algún error, verás lo que se esperaba y lo que recibió el comando para la prueba.

Verás el siguiente resultado en tu terminal.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage verify --verbose
INFO[02-09|08:30:19] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command terraform with args [output -no-color -json names_list]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:179: ["multiple-buckets-erp1-eu-one","multiple-buckets-erp1-eu-two"]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command gcloud with args [alpha storage ls --buckets gs://multiple-buckets-erp1-eu-one --project ci-cloud-storage-8ce9 --json]
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: [
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: {
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179:   "url": "gs://multiple-buckets-erp1-eu-one/",
...
TestMultipleBuckets 2022-02-09T08:30:33Z command.go:179: ]
2022/02/09 08:30:33 RUN_STAGE env var set to verify
2022/02/09 08:30:33 Skipping stage teardown
--- PASS: TestMultipleBuckets (12.32s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    12.359s

7. Ejecuta cft test run <EXAMPLE_NAME> --stage teardown para desmantelar el ejemplo.

En este paso, se destruye la infraestructura que creaste en los pasos anteriores. En este paso, también se destruirán los buckets de GCS que se crearon en el proyecto junto con la etiqueta que agregaste al módulo de GCS.

Puedes ver el siguiente resultado en tu terminal.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage teardown --verbose
INFO[02-09|08:36:02] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:36:06Z command.go:100: Running command terraform with args [destroy -auto-approve -input=false -lock=false]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: module.cloud_storage.random_id.bucket_suffix: Refreshing state... [id=mNA]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: random_string.prefix: Refreshing state... [id=erp1]
TestMultipleBuckets 2022-02-09T08:36:08Z command.go:179: module.cloud_storage.google_storage_bucket.buckets["two"]: Refreshing state... [id=multiple-buckets-erp1-eu-two]
...
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: Destroy complete! Resources: 6 destroyed.
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: 
--- PASS: TestMultipleBuckets (6.62s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.654s

8. Ejecuta module-swapper -registry-prefix=terraform-google-modules -restore ​para deshacer los ajustes en los archivos main.tf de ejemplo de la última vez que ejecutaste module-swapper.

[root@<CONTAINER_ID> workspace]# module-swapper -registry-prefix=terraform-google-modules -restore
2025/08/04 19:30:41 Module name set from remote to cloud-storage
2025/08/04 19:36:32 Modifications made to file /workspace/examples/multiple_buckets/main.tf
2025/08/04 19:36:32 --- Original
+++ Modified
@@ -21,8 +21,8 @@
 }
 
 module "cloud_storage" {
-  source = "../.."
-   version = "~> 10.0"
+  source  = "terraform-google-modules/cloud-storage/google"
+  version = "~> 10.0"
 
   project_id = var.project_id
 

9. Ejecuta exit para salir del contenedor de prueba.

9. Generación de documentación para entradas y salidas

Las tablas de entradas y salidas en los archivos README del módulo raíz, los submódulos y los módulos de ejemplo se generan automáticamente en función de los elementos variables y outputs de los módulos respectivos. Estas tablas se deben actualizar si se cambian las interfaces del módulo.

Ejecuta lo siguiente:

make generate_docs
# This will generate new Inputs and Outputs tables

Recuerda: Siempre ejecuta generate_docs para asegurarte de que toda la documentación esté completa.

10. Ejecuta pruebas de lint en CFT

Un linter es una herramienta que analiza el código fuente para marcar errores de programación, errores, errores de estilo y construcciones sospechosas.

Muchos de los archivos del repositorio se pueden verificar o formatear para mantener un estándar de calidad. Para garantizar la calidad en CFT, usarás una prueba de lint.

Ejecuta lo siguiente:

make docker_test_lint
# This will run all lint tests on your repo

Recuerda: Siempre ejecuta la prueba de lint, ya que Cloud Build fallará si no se completa el análisis de lint. Ejecuta este comando antes de confirmar el código en tu repo local.

11. Envía una solicitud de extracción en GitHub

Nota: En este punto, el codelab está completo. Te recomendamos que crees una solicitud de extracción solo si eres nuevo en GitHub y quieres aprender el proceso.

Ahora que cambiaste tu código de forma local y lo probaste con las pruebas de integración, querrás publicarlo en el repositorio principal.

Para que tu código esté disponible en el repositorio principal, deberás confirmar los cambios de código en tu rama y enviarlos al repositorio principal. Para que tu código se agregue al repositorio principal que bifurcaste al inicio del codelab, deberás enviar una solicitud de extracción (PR) al repositorio principal después de confirmar el código en tu repositorio.

Cuando envíes una solicitud de extracción, se notificará al administrador del repositorio para que revise los cambios de código propuestos. Además, también puedes agregar a otros usuarios como revisores para obtener comentarios sobre los cambios en tu código. La PR activará una compilación de Cloud Build que ejecutará pruebas en el repositorio.

Según los cambios que realices en el código, los revisores de código te proporcionarán comentarios y te pedirán que realices modificaciones si es necesario cambiar algo según las prácticas recomendadas y la documentación. El administrador revisará los cambios en tu código, se asegurará de que cumpla con los requisitos del repositorio y es posible que te solicite que realices algunos cambios antes de fusionar tu código en el repositorio principal.

Ejecuta los siguientes pasos para confirmar el código en tu rama bifurcada y enviarlo a ella:

1. El primer paso es agregar los archivos modificados al repositorio local.

$ git add main.tf
$ git add README.md
$ git add variables.tf
$ git add examples/multiple-buckets/main.tf
$ git add test/integration/multiple_buckets/multiple_buckets_test.go
# The ‘git add' command adds the file in the local repository and 
# stages the file for commit. To unstage a file, use git reset HEAD YOUR-FILE

2. Tus archivos ahora están en la etapa de espera. A continuación, confirmarás los cambios.

$ git commit -m "First CFT commit"
# This will commit the staged changes and prepares them to be pushed 
# to a remote repository. To remove this commit and modify the file, 
# use 'git reset --soft HEAD~1' and commit and add the file again.

3. Envía los cambios confirmados en tu repositorio local a GitHub para crear una solicitud de extracción (PR).

$ git push -u origin feature/silly_label
# Pushes the changes in your local repository up to the remote
# repository you specified as the origin

Tus cambios de código ya están listos para una solicitud de extracción.

Sigue estos pasos para crear una PR en el repositorio terraform-google-modules/terraform-google-cloud-storage :

1. En tu navegador web, ve a la página principal del repo.
2. Verás una sugerencia a través de un banner para abrir una solicitud de extracción desde tu bifurcación. Haz clic en “Compare and pull request”.

3. Ingresa un título y una descripción para tu solicitud de extracción que describan los cambios en el código. Sé lo más específico posible, pero también conciso.

4. Para crear una solicitud de extracción lista para su revisión, haz clic en "Crear solicitud de extracción".
5. Verás que se ejecutan los activadores de Cloud Build que se activaron debido a la PR.
6. Si tienes algún problema, consulta la documentación oficial de GitHub sobre cómo abrir solicitudes de extracción desde bifurcaciones.

Enviaste correctamente tu primer cambio de código a la rama bifurcada y creaste tu primera PR de CFT en la rama principal.

12. Felicitaciones

¡Felicitaciones! Agregaste correctamente una función a un módulo de CFT y enviaste una PR para su revisión.

Agregaste una función a un módulo de CFT, la probaste de forma local con un ejemplo y realizaste pruebas antes de confirmar tu código en GitHub. Por último, creaste una PR para su revisión y combinación final en CFT.

Ahora conoces los pasos importantes para comenzar a usar Cloud Foundation Toolkit.