Se usó la API de Cloud Translation para traducir esta página.

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 a usar Google Cloud Platform rápidamente. En este instructivo, aprenderás a contribuir al kit de herramientas de Cloud Foundation.

Requisitos

Una cuenta de GitHub
Docker instalado en tu máquina o usa Cloud Shell ( instalación en Mac, instalación en Windows).
Editor de código para editar código (por 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 de proyectos 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 a Cloud Foundation Toolkit (CFT).

Harás lo siguiente:

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

Para ejecutar todos los pasos anteriores, agregarás una función nueva 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 podrás escribir 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 el entorno de desarrollo en tu máquina.

Configura Git

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

Cuando usas Cloud Shell, no necesitas instalar Git, ya que está preinstalado.

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

Si estás configurando tu entorno de desarrollo en tu máquina, debes instalar Git.

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

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

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

Configuraste Git correctamente y deberías poder bifurcar, crear y clonar ramas. En este codelab, usaremos Git de forma extensa.

3. Cómo bifurcar el repositorio de GCS de CFT

Cómo bifurcar un repositorio de CFT

En el paso anterior, configuraste Git en tu máquina local o en Cloud Shell. Ahora, debes bifurcar el repositorio 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, se usan para proponer cambios en el proyecto de otra persona o para usarlo 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.
Corrige los errores.
Envía una solicitud de extracción al propietario del proyecto.

Pasos para bifurcar un repositorio de CFT:

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

Verás una opción para saber dónde quieres colocar la bifurcación, elegir tu perfil y se bifurcará el repo.

Clona tu bifurcación de forma local

La bifurcación que creaste es una copia del repositorio de módulos de GCS. Ahora clonarás este repositorio en tu entorno local para agregar el atributo nuevo.

Sigue estos pasos para clonar la bifurcación:

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

Después de hacer clic en el botón “Code”, haz clic en el ícono “Copy” para copiar la URL de la bifurcación. Usarás esta URL para clonar la bifurcación en tu entorno local.

Ve a una terminal en VSCode o 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.

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

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

Para solicitudes de funciones: feature/feature-name
Para actualizaciones internas, internal/change-name
Para correcciones de errores: bugfix/issue-name

Dado que estás agregando una función nueva, 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 utilizas tu máquina con fines de desarrollo, debes instalar Docker Engine.

1. Instala el SDK de Google Cloud

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

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

2. Cómo establecer la 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 se deben establecer 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 pruebas, debes descargar una clave de cuenta de servicio a tu entorno de pruebas. Esta cuenta de servicio necesitará los roles de Creador de proyectos, Usuario de la cuenta de facturación y Visualizador de la organización. Estos pasos te ayudarán 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 para 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 de proyectos, usuario de la cuenta de facturación y visor 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 prueba.

4. Prepara la credencial 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 la credencial de Terraform

Proporciona 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 credenciales en la variable de entorno, quita el archivo de claves. Si es necesario, puedes volver a crear una clave más adelante 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

Cuando ejecutes make docker_test_prepare, verás el siguiente resultado. Al final, recibirás el project_id de prueba que se creó, en el que implementarás y probarás tu módulo de Cloud Storage con la 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.

Ya creaste un proyecto de prueba al que hace referencia project_id, como se puede ver en el resultado de la consola. Se configuró tu entorno de desarrollo y pruebas.

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

Ahora que se configuraron los entornos de desarrollo y pruebas, comencemos a agregar la función "silly_label" al módulo de CFT 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 el atributo 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 y agrégalo a la línea 31 en variables.tf. Asegúrate de tener un nuevo carácter de línea arriba y debajo 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 a main.tf del módulo y ahora la probarás a través de un ejemplo.

Se deberá agregar "silly_label" a examples/multiple-buckets/main.tf.

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

Copia y pega la siguiente línea de 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 la función mediante una prueba de integración de plano 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 "silly_label" a 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 de almacenamiento de gcloud alpha y, luego, verificas el resultado que se muestra.

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 estar acompañados de pruebas.

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

La estrategia general de estas pruebas es verificar el comportamiento de los módulos de ejemplo, lo que garantiza que el módulo raíz, los submódulos y los módulos de ejemplo sean funcionalmente correctos.

En la ejecución interactiva, cada paso se realiza mediante varios comandos.

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

Make es una herramienta de automatización de compilación 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 de destino. Cuando realices cambios en los archivos, el contenedor de Docker se debe actualizar automáticamente.

Cuando ejecutes make docker_run, crearás un lugar de trabajo en tu contenedor de Docker y activarás las credenciales para tu cuenta de servicio. El espacio de trabajo se usará en los próximos pasos para ejecutar pruebas.

Verás el siguiente resultado en la terminal:

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

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

Verás el siguiente resultado en la 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

Ejecuta cft test run <EXAMPLE_NAME> --stage init para inicializar el ejemplo. En este caso, para inicializar la ejecución de prueba TestMultipleBuckets, es cft test run TestMultipleBuckets --stage init. Además, puedes usar la marca --verbose para obtener información adicional cuando ejecutes pruebas.

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

Verás el siguiente resultado en la 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)

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 creado antes 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

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 mediante la ejecución de un comando gcloud para recuperar el resultado JSON del estado actual de un recurso y confirmar que el estado actual sea como 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 la terminal.

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

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

Este paso destruye la infraestructura que creaste en los pasos anteriores. Este paso también destruirá 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

Ejecuta exit para salir del contenedor de prueba.

9. Genera documentación para entradas y salidas

Las tablas de entradas y salidas de 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 variables y outputs de los módulos respectivos. Estas tablas se deben actualizar si se cambian las interfaces del módulo.

Ejecuta:

make generate_docs
# This will generate new Inputs and Outputs tables

10. Cómo ejecutar pruebas de lint en CFT

Un lint es una herramienta que analiza el código fuente para marcar errores de programación, errores tipográficos y construcciones sospechosas.

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

Ejecuta:

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

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

Ahora que cambiaste tu código de forma local y lo probaste a través de las pruebas de integración, te recomendamos que lo publiques 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 enviarlo al repositorio principal. Para que tu código se agregue al repositorio principal que bifurcaste al comienzo del codelab, generarás una solicitud de extracción (PR) en el repositorio principal después de confirmar el código en tu repositorio.

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

En función de los cambios que realices en el código, los revisores te enviarán comentarios y te pedirán que realices modificaciones si es necesario en función de las prácticas recomendadas y la documentación. El administrador revisará los cambios de código, se asegurará de que cumpla con el repositorio y es posible que vuelva a solicitarte que realices algunos cambios antes de fusionarlo en el repositorio principal.

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

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

Tus archivos ahora están en la etapa de preparación. 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.

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

Los cambios en tu código ya están listos para una solicitud de extracción.

Ejecuta los siguientes pasos para crear una PR en el repositorio terraform-google-modules/terraform-google-cloud-storage :

En tu navegador web, navega a la página principal del repositorio.
Verás una sugerencia en el banner para abrir una solicitud de cambios desde tu bifurcación. Haz clic en "Compare and pull request".

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

Si deseas crear una solicitud de extracción lista para su revisión, haz clic en “Crear solicitud de extracción”.
Verás que se ejecutan los activadores de Cloud Build que se activan debido a la PR.
Consulta la documentación oficial de GitHub sobre cómo abrir solicitudes de extracción desde bifurcaciones si tienes algún problema.

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

12. Felicitaciones

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

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

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