Guida introduttiva al toolkit di Cloud Foundation

1. Introduzione a CFT 101

Ultimo aggiornamento: 11/02/2022

Che cos'è Cloud Foundation Toolkit?

In sostanza, CFT fornisce modelli di best practice per iniziare rapidamente a utilizzare Google Cloud Platform. In questo tutorial imparerai a contribuire a Cloud Foundation Toolkit.

Che cosa ti serve

• Un account GitHub.
• Docker installato sulla tua macchina o utilizza Cloud Shell ( installazione su Mac, installazione su Windows)
• Editor di codice per la modifica del codice (ad esempio Visual Studio Code)
• Familiarità di base con Git e GitHub
• Esperienza con Terraform e Infrastructure as Code
• Autorizzazione per concedere il ruolo Creatore progetto a un service account
• Un'organizzazione Google Cloud, una cartella di test e un account di fatturazione

Cosa creerai

In questo codelab imparerai a contribuire a Cloud Foundation Toolkit (CFT).

Imparerai a:

• Configura un ambiente di sviluppo per contribuire a CFT
• Aggiungere una funzionalità a un modulo CFT
• Aggiungere test per la funzionalità aggiunta
• Esegui test di integrazione in CFT
• Esegui test lint
• Esegui il commit del codice in GitHub e invia una richiesta di pull

Eseguirai tutti i passaggi precedenti aggiungendo una nuova funzionalità al modulo CFT di Google Cloud Storage. Aggiungerai un'etichetta chiamata "silly_label", che verrà aggiunta automaticamente a tutti i bucket creati tramite il modulo CFT di GCS. Potrai anche scrivere test per convalidare la tua funzionalità e garantire l'integrazione end-to-end.

2. Configurare l'ambiente di sviluppo

Se vuoi, puoi utilizzare Cloud Shell per i tuoi scopi di sviluppo. Se non vuoi utilizzare Cloud Shell per contribuire a CFT, puoi configurare l'ambiente di sviluppo sulla tua macchina.

Configurare Git

GitHub si basa su un sistema di controllo della versione (VCS) open source chiamato Git. Git è responsabile di tutto ciò che riguarda GitHub e che avviene localmente sul tuo computer o in Cloud Shell.

1. Quando utilizzi Cloud Shell, non devi installare Git perché è preinstallato.

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

Se stai configurando l'ambiente di sviluppo sulla tua macchina, devi installare Git.

Scarica e installa l'ultima versione di Git

Impostare il nome utente e l'email in Git

Git utilizza un nome utente per associare i commit a un'identità. Il nome utente Git non è lo stesso del nome utente GitHub.

Puoi modificare il nome associato ai tuoi commit Git utilizzando il comando git config. La modifica del nome associato ai commit Git utilizzando git config influirà solo sui commit futuri e non cambierà il nome utilizzato per i commit precedenti.

Impostare il nome utente Git per ogni repository sul computer

Per Mac/Linux: apri un terminale

Per Windows: apri Git Bash

Imposta un nome utente Git:

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

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

Conferma di aver impostato correttamente il nome utente Git:

$ git config --list

> Your Name

> Your Email

Hai configurato Git correttamente e dovresti essere in grado di creare fork, creare e clonare rami. In questo codelab utilizzeremo Git in modo intensivo.

3. Crea un fork del repository GCS di CFT

Creare un fork di un repository CFT

Hai configurato Git sulla tua macchina locale o su Cloud Shell nel passaggio precedente. Ora devi eseguire il fork del repository CFT di Google Cloud Storage per iniziare a contribuire.

Un fork è una copia di un repository. Il fork di un repository ti consente di sperimentare liberamente le modifiche senza influire sul progetto originale.

In genere, i fork vengono utilizzati per proporre modifiche al progetto di un altro utente o per utilizzare il progetto di un altro utente come punto di partenza per la tua idea.

Ad esempio, puoi utilizzare i fork per proporre modifiche relative alla correzione di un bug. Per correggere un bug, puoi:

• Crea un fork del repository.
• Apporta la correzione.
• Invia una richiesta di pull al proprietario del progetto.

Passaggi per creare un fork di un repository CFT:

1. Apri il browser web e vai al repository terraform-google-modules/terraform-google-cloud-storage. Utilizzeremo questo repository per l'intero codelab.
2. Nell'angolo in alto a destra della pagina, fai clic su Fork.

3. Ti verrà presentata un'opzione per scegliere dove vuoi creare il fork. Scegli il tuo profilo e il repository verrà creato.

Clonare il fork in locale

Il fork che hai creato è una copia del repository del modulo GCS. Ora clona questo repository nel tuo ambiente locale per aggiungere la nuova funzionalità.

Passaggi per clonare il fork:

1. Apri il browser web e vai al tuo fork su terraform-google-modules/terraform-google-cloud-storage.
2. Nell'angolo in alto a destra, fai clic sul pulsante "Codice".

3. Dopo aver fatto clic sul pulsante "Codice", fai clic sull'icona "Copia" per copiare l'URL del fork. Utilizzerai questo URL per clonare il fork nell'ambiente locale.

4. Vai a un terminale in VSCode o sulla tua macchina e clona il fork.

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

5. Ora che hai clonato il fork localmente, devi accedere al repository, creare un nuovo branch dal fork e apportare modifiche al codice nel branch temporaneo.

Per convenzione, puoi assegnare al ramo il nome seguente:

• Per le richieste di funzionalità: feature/feature-name
• Per gli aggiornamenti interni, internal/change-name
• Per le correzioni di bug: bugfix/issue-name

Poiché stai aggiungendo una nuova funzionalità, puoi chiamare il ramo temporaneo 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"

Ora è tutto pronto per iniziare a lavorare su Cloud Foundation Toolkit.

4. Creare un ambiente di test

Il processo di sviluppo CFT standard si basa sull'utilizzo di un progetto di test isolato per i test. Questo passaggio ti guiderà nella creazione del progetto di test (basato su una configurazione standard) tramite un service account.

0. Installa Docker Engine

Se utilizzi la tua macchina a scopo di sviluppo, devi installare Docker Engine.

Nota: se utilizzi Cloud Shell, non è necessario installare Docker perché è già presente.

1. Installa Google Cloud SDK

Non è necessario installare Google Cloud SDK se utilizzi Cloud Shell di GCP.

Vai a Google Cloud SDK e scarica il programma di installazione interattivo per la tua piattaforma.

2. Imposta configurazione

Per creare un ambiente di test, devi disporre di un'organizzazione Google Cloud, di una cartella di test e di un account di fatturazione. Questi valori devono essere impostati tramite le variabili di ambiente:

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. Configurare il service account

Prima di creare un ambiente di test, devi scaricare una chiave del service account nell'ambiente di test. Questo service account avrà bisogno dei ruoli Creatore progetto, Utente account di fatturazione e Visualizzatore organizzazione. Questi passaggi ti aiutano a creare un nuovo service account, ma puoi anche riutilizzarne uno esistente.

3.1 Crea o seleziona il progetto GCP iniziale

Prima di creare il service account, devi selezionare un progetto in cui ospitarlo. Puoi anche creare un nuovo progetto.

gcloud config set core/project YOUR_PROJECT_ID

3.2 Attiva le API Google Cloud

Abilita le seguenti API Google Cloud nel progetto seed:

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

3.3 Crea service account

Crea un nuovo service account per gestire l'ambiente di test:

# 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 che il service account sia stato creato:

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

3.4 Concedi i ruoli Autore progetto, Utente account di fatturazione e Visualizzatore organizzazione al service account:

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"

Ora hai un service account che può essere utilizzato per gestire l'ambiente di test.

4. Prepara le credenziali Terraform

Per creare l'ambiente di test, devi scaricare la chiave del service account nella shell.

4.1 Chiave service account

Crea e scarica una chiave del service account per Terraform

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

4.2 Configurare le credenziali Terraform

Fornisci la chiave a Terraform utilizzando la variabile di ambiente SERVICE_ACCOUNT_JSON, impostando il valore sul contenuto della chiave del service account.

export SERVICE_ACCOUNT_JSON=$(< cft.json)

Dopo aver memorizzato le informazioni sulle credenziali nella variabile di ambiente, rimuovi il file delle chiavi. Se necessario, puoi ricreare una chiave in un secondo momento utilizzando lo stesso comando riportato sopra.

rm -rf cft.json

5. Crea un progetto di test per i deployment di Terraform

Ora che tutto è pronto, puoi creare il progetto di test con un solo comando. Esegui questo comando dalla radice della directory terraform-google-cloud-storage:

make docker_test_prepare

Quando esegui make docker_test_prepare, vedrai l'output riportato di seguito. Alla fine riceverai il project_id di test creato, in cui eseguire il deployment e testare il modulo Cloud Storage con la nuova funzionalità. Se riscontri problemi con il collegamento di un account di fatturazione, consulta i passaggi per la risoluzione dei problemi.

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.

Ora hai creato un progetto di test a cui viene fatto riferimento da project_id, come puoi vedere nell'output della console. L'ambiente di sviluppo e di test è configurato.

5. Aggiungere una nuova funzionalità al modulo CFT

Ora che l'ambiente di sviluppo e test è configurato, iniziamo ad aggiungere la funzionalità "silly_label" al modulo CFT google-cloud-storage.

Assicurati di trovarti in terraform-google-cloud-storage e apri il file main.tf come mostrato di seguito nella struttura delle cartelle.

Poiché "silly_label" è un'etichetta, aggiungerai la funzionalità alla riga 27 nella variabile "labels" di main.tf, come mostrato di seguito:

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(
 <...>
}

Ora aggiungi la variabile silly_label nel file variables.tf che vedi nella struttura delle cartelle riportata sopra.

Copia e incolla il codice riportato di seguito e aggiungilo alla riga 31 di variables.tf. Assicurati di avere un carattere di nuova riga sopra e sotto il blocco di variabili che aggiungi.

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. Aggiungere una nuova funzionalità all'esempio di bucket di archiviazione

Hai aggiunto la funzionalità al file main.tf del modulo e ora la testerai tramite un esempio.

L'etichetta "silly_label" dovrà essere aggiunta a examples/multiple-buckets/main.tf

Questo esempio verrà utilizzato nel passaggio successivo per eseguire i test di integrazione.

Copia e incolla la riga della variabile silly_label riportata di seguito nella riga 27 di main.tf in terraform-google-cloud-storage/examples/multiple-buckets/, come mostrato nella struttura delle cartelle:

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. Aggiorna il test del progetto per controllare la funzionalità

Hai aggiunto la funzionalità al file main.tf del modulo e poi all'esempio multiple_buckets. Ora devi testare la funzionalità tramite un test di integrazione del blueprint scritto in Golang.

Aggiungerai i nuovi test nel file multiple_buckets_test.go che si trova nella seguente struttura di cartelle:

Hai aggiunto l'etichetta "silly_label" a tutti i bucket creati tramite il modulo multiple_buckets e ora devi scrivere test per provare la nuova funzionalità.

Nel codice riportato di seguito, ottieni l'etichetta di ogni bucket tramite il comando gcloud alpha storage e poi controlli l'output restituito dal 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. Esegui test di integrazione in CFT

Test di integrazione

I test di integrazione vengono utilizzati per verificare il comportamento del modulo radice, dei sottomoduli e degli esempi. Aggiunte, modifiche e correzioni devono essere accompagnate da test.

I test di integrazione vengono scritti utilizzando il framework di test blueprint ed eseguiti utilizzando la CLI CFT. Questi strumenti sono inclusi in un'immagine Docker per comodità.

La strategia generale per questi test è verificare il comportamento dei moduli di esempio, garantendo così che il modulo principale, i sottomoduli e i moduli di esempio siano tutti funzionalmente corretti.

Nell'esecuzione interattiva, esegui ogni passaggio tramite più comandi.

1. Esegui make docker_run per avviare il container Docker di test in modalità interattiva.

Make è uno strumento di automazione della compilazione che crea automaticamente programmi eseguibili e librerie dal codice sorgente leggendo file denominati Makefile, che specificano come derivare il programma di destinazione. Quando apporti modifiche ai file, il container Docker deve essere aggiornato automaticamente.

Quando esegui make docker_run, crei uno spazio di lavoro nel container Docker e attivi le credenziali per il tuo service account. Lo spazio di lavoro verrà utilizzato nei passaggi successivi per eseguire i test.

Nel terminale vedrai l'output seguente:

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

2. Esegui module-swapper -registry-prefix=terraform-google-modules per modificare i file di esempio main.tf in modo da importare i moduli dai file locali anziché dai moduli pubblicati.

Nel terminale dovresti vedere un output simile al seguente:

[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. Esegui cft test list per elencare tutti i test dei progetti nel tuo spazio di lavoro.

Nel terminale vedrai l'output seguente:

[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. Esegui cft test run <EXAMPLE_NAME> --stage init per inizializzare l'esempio. In questo caso, per inizializzare l'esecuzione del test TestMultipleBuckets, cft test run TestMultipleBuckets --stage init. Puoi anche utilizzare il flag --verbose per ottenere informazioni aggiuntive durante l'esecuzione dei test.

Questa fase di inizializzazione inizializza l'esempio Terraform.

Nel terminale verrà visualizzato l'output riportato di seguito.

[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:nei log potrebbero essere visualizzati avvisi come Skipping fixtures discovery. Si tratta di avvisi per il debug che possono essere ignorati. Se vengono rilevati errori, il test non andrà a buon fine.

5. Esegui cft test run <EXAMPLE_NAME> --stage apply per applicare il modulo di esempio.

Questo passaggio applica l'esempio inizializzato nella fase precedente al progetto GCP creato in precedenza nel Codelab.

Nel terminale verrà visualizzato l'output riportato di seguito.

[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:se nei log viene visualizzato Request violates constraint 'constraints/storage.uniformBucketLevelAccess', è perché il tuo progetto non può impostare uniform_bucket_level_access su false. Per questo codelab, puoi aggirare il problema impostando cloud_storage.bucket_policy_only["two"] su true anziché false e modificando di conseguenza il test Golang.

6. Esegui cft test run <EXAMPLE_NAME> --stage verify per verificare che l'esempio abbia creato l'infrastruttura prevista.

Questo passaggio eseguirà la funzione di verifica in TestMultipleBuckets. In genere, la verifica viene eseguita tramite l'esecuzione di un comando gcloud per recuperare l'output JSON per lo stato attuale di una risorsa e verificare che lo stato attuale sia quello dichiarato nell'esempio.

Se ricevi errori, vedrai cosa era previsto e cosa è stato ricevuto dal comando per il test.

Nel terminale verrà visualizzato l'output riportato di seguito.

[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. Esegui cft test run <EXAMPLE_NAME> --stage teardown per smontare l'esempio.

Questo passaggio distrugge l'infrastruttura che hai creato nei passaggi precedenti. Questo passaggio distruggerà anche i bucket GCS creati nel progetto insieme all'etichetta aggiunta al modulo GCS.

Puoi visualizzare l'output riportato di seguito nel terminale.

[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. Esegui module-swapper -registry-prefix=terraform-google-modules -restore per annullare le modifiche apportate ai file di esempio main.tf dall'ultima volta che hai eseguito 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. Esegui exit per uscire dal container di test.

9. Generazione della documentazione per input e output

Le tabelle Input e Output nei file README del modulo radice, dei sottomoduli e dei moduli di esempio vengono generate automaticamente in base a variables e outputs dei rispettivi moduli. Queste tabelle devono essere aggiornate se le interfacce del modulo vengono modificate.

Esegui:

make generate_docs
# This will generate new Inputs and Outputs tables

Ricorda:esegui sempre generate_docs per assicurarti che tutta la documentazione sia completa.

10. Esegui test lint in CFT

Un linter è uno strumento che analizza il codice sorgente per segnalare errori di programmazione, bug, errori stilistici e costrutti sospetti.

Molti dei file nel repository possono essere analizzati o formattati per mantenere uno standard di qualità. Per garantire la qualità in CFT, utilizzerai un test lint.

Esegui:

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

Ricorda:esegui sempre il test lint perché Cloud Build non andrà a buon fine se il linting non è completo. Esegui questo comando prima di eseguire il commit del codice nel repository locale.

11. Invio di una richiesta di pull su GitHub

Nota:a questo punto, il codelab è completo. Ti invitiamo a creare una richiesta di pull solo se non hai mai usato GitHub e vuoi imparare la procedura.

Ora che hai modificato il codice localmente e lo hai testato tramite i test di integrazione, devi pubblicarlo nel repository principale.

Per rendere disponibile il codice nel repository principale, devi eseguire il commit delle modifiche al codice nel tuo ramo ed eseguirne il push nel repository principale. Affinché il tuo codice venga aggiunto al repository principale di cui hai creato un fork all'inizio del codelab, devi inviare una richiesta pull (PR) al repository principale dopo aver eseguito il commit del codice nel tuo repository.

Quando crei una richiesta pull, l'amministratore del repository riceve una notifica per esaminare le modifiche al codice proposte. Inoltre, puoi aggiungere altri utenti come revisori per ricevere feedback sulle modifiche al codice. La richiesta pull attiverà una build di Cloud Build che eseguirà test sul repository.

In base alle modifiche al codice, i revisori del codice forniranno commenti sul codice e chiederanno modifiche se qualcosa deve essere cambiato in base alle best practice e alla documentazione. L'amministratore esaminerà le modifiche al codice, si assicurerà che sia conforme al repository e potrebbe chiederti di apportare alcune modifiche prima di unire il codice al repository master.

Esegui i seguenti passaggi per eseguire il commit del codice nel ramo forked e il push del codice nel ramo forked:

1. Il primo passaggio consiste nell'aggiungere i file modificati al repository locale.

$ 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. Ora i file sono in staging, il passaggio successivo è il commit delle modifiche.

$ 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. Esegui il push delle modifiche di cui è stato eseguito il commit nel repository locale su GitHub per creare una richiesta di pull.

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

Le modifiche al codice sono ora pronte per una richiesta pull.

Esegui i seguenti passaggi per creare una richiesta di pull per il repository terraform-google-modules/terraform-google-cloud-storage:

1. Nel browser web, vai alla pagina principale del repo.
2. Vedrai un suggerimento tramite banner per aprire una richiesta pull dal tuo fork. Fai clic su "Confronta e pull request".

3. Inserisci un titolo e una descrizione per la richiesta di pull per descrivere le modifiche al codice. Fornisci informazioni quanto più specifiche possibile, ma in modo conciso.

4. Per creare una pull request pronta per la revisione, fai clic su "Crea pull request".
5. Verranno eseguiti i trigger Cloud Build attivati a causa della richiesta di pull.
6. In caso di problemi, consulta la documentazione ufficiale di GitHub sull'apertura di richieste di pull da fork.

Hai eseguito correttamente il push della prima modifica del codice nel ramo forked e hai creato la prima richiesta di pull CFT rispetto al ramo master.

12. Complimenti

Congratulazioni, hai aggiunto correttamente una funzionalità a un modulo CFT e hai inviato una richiesta pull per la revisione.

Hai aggiunto una funzionalità a un modulo CFT, l'hai testata localmente tramite un esempio e hai eseguito dei test prima di eseguire il commit del codice su GitHub. Infine, hai creato una richiesta di pull per la revisione e l'unione finale in CFT.

Ora conosci i passaggi importanti per iniziare a utilizzare Cloud Foundation Toolkit.