Go-Anwendungen erstellen und testen

Auf dieser Seite wird erläutert, wie Sie mit Cloud Build Ihre Go-Anwendungen erstellen und testen, Ihre Artefakte in Artifact Registry hochladen, Herkunftsinformationen generieren und Ihre Testlogs in Cloud Storage speichern.

Hinweis

Die Anleitung auf dieser Seite setzt voraus, dass Sie mit Go vertraut sind. Außerdem gilt:

  • Aktivieren Sie die Cloud Build API, die Cloud Run API und die Artifact Registry API.

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Weitere Informationen zum Zuweisen von Rollen

    APIs aktivieren

  • Zum Ausführen der gcloud-Befehle auf dieser Seite müssen Sie die Google Cloud CLI installieren.
  • Halten Sie Ihr Go-Projekt bereit.
  • Sie haben ein Go-Repository in Artifact Registry. Wenn Sie noch keines haben, erstellen Sie ein neues Repository.
  • Wenn Sie Testlogs in Cloud Storage speichern oder die gcloud CLI zum Starten des Builds verwenden möchten, erstellen Sie einen Bucket in Cloud Storage.
  • Achten Sie darauf, dass Sie die ID des Laufzeitdienstkontos für Cloud Run kennen.

Benutzerdefiniertes Cloud Build-Dienstkonto erstellen

Erstellen Sie ein benutzerdefiniertes Cloud Build-Dienstkonto, indem Sie den folgenden Befehl in der Google Cloud CLI ausführen:

  gcloud iam service-accounts create cloud-build-go \
      --description="Build and test Go applications" \
      --display-name="Cloud Build Go" \
      --project="PROJECT_ID"

Ersetzen Sie dabei PROJECT_ID durch die ID Ihres Projekts in Google Cloud . Wenn das Flag weggelassen wird, wird das aktuelle Projekt angenommen.

Mit diesem Dienstkonto erstellen und testen Sie Ihre Go-Anwendung.

IAM-Berechtigungen konfigurieren

So konfigurieren Sie Ihr neues Dienstkonto mit den Berechtigungen, die zum Erstellen und Bereitstellen von Go-Anwendungen erforderlich sind:

  1. Rufen Sie in der Google Cloud Console die Seite Cloud Build Berechtigungen auf:

    Berechtigungen aufrufen

  2. Rufen Sie das Menü Dienstkonto auf und wählen Sie Ihr cloud-build-go-Dienstkonto aus.

  3. Setzen Sie den Status der folgenden Rollen auf Aktiviert:

    • Cloud Run-Administrator (roles/run.admin): Ermöglicht Cloud Build, neue Dienste in Cloud Run bereitzustellen.
    • Storage-Administrator (roles/storage.admin): Ermöglicht das Lesen und Schreiben in Cloud Storage.
    • Artifact Registry-Autor (roles/artifactregistry.writer): Ermöglicht das Abrufen von Images aus und das Schreiben in Artifact Registry.
    • Logs Writer (roles/logging.logWriter): Ermöglicht das Schreiben von Logeinträgen in Cloud Logging.
    • Cloud Build-Bearbeiter (roles/cloudbuild.builds.editor): Ermöglicht Ihrem Dienstkonto, Builds auszuführen.

Go-Builds konfigurieren

Das öffentliche golang-Image von Docker Hub unterstützt das Erstellen mithilfe von Go-Modulen. Wenn Sie dieses Image als Build-Schritt in Ihrer Cloud Build-Konfigurationsdatei verwenden, können Sie im Image go-Befehle aufrufen. Argumente, die an diesen Build-Schritt übergeben werden, werden direkt an das golang-Tool weitergegeben, sodass Sie in diesem Image alle go-Befehle ausführen können.

In diesem Abschnitt wird gezeigt, wie Sie eine Beispiel-Build-Konfigurationsdatei für eine Go-Anwendung aus dem Git-Repository cloud-build-samples erstellen. Die Build-Konfigurationsdatei enthält Schritte zum Erstellen der App, zum Hinzufügen von Einheitentests und zum Bereitstellen der App, nachdem die Tests bestanden wurden.

So erstellen Sie die Beispiel-Go-Anwendung:

  1. Einheitentests konfigurieren: Wenn Sie in Ihrer Anwendung Einheitentests definiert haben, können Sie Cloud Build so konfigurieren, dass die Tests ausgeführt werden. Fügen Sie dazu die folgenden Felder in einem Build-Schritt hinzu:

    • name: Legen Sie den Wert dieses Felds auf golang fest, um das Golang-Image von Docker Hub für Ihre Aufgabe zu verwenden.
    • entrypoint: Legen Sie den Wert dieses Felds auf /bin/bash fest. Auf diese Weise können Sie mehrzeilige Bash-Befehle direkt aus dem Build-Schritt ausführen.

    • args: Im Feld args eines Build-Schritts wird eine Liste von Argumenten abgerufen und an das Image übergeben, auf das im Feld name verwiesen wird. Im folgenden Beispiel verwendet das Feld args die Argumente für:

      • Ausführen des Testlog-Formatierers zum Herunterladen der Testlogausgabe.
      • Ausgeben der Logausgabe.
      • Speichern der Testergebnisse in sponge.log.

      • Ausgabe der Ergebnisse in sponge.log in eine JUnit-XML-Datei Der Name der JUnit-XML-Datei wird mit der kurzen Version der Commit-ID erstellt, die Ihrem Build zugeordnet ist. Bei einem nachfolgenden Build-Schritt werden die Logs in dieser Datei in Cloud Storage gespeichert.

        steps:
  # Run tests and save to file
  - name: golang:1.23
    entrypoint: /bin/bash
    args:
      - -c
      - |
        go install github.com/jstemmer/go-junit-report/v2@latest
        2>&1 go test -timeout 1m -v ./... | /go/bin/go-junit-report -set-exit-code -iocopy -out ${SHORT_SHA}_test_log.xml

  2. In Artifact Registry hochladen: Geben Sie in Ihrer Konfigurationsdatei mit dem Feld goModules den Anwendungspfad und Ihr Go-Repository in Artifact Registry an:

    # Upload Go module to artifact registry
artifacts:
  goModules:
    - repositoryName: 'repositoryName'
      repositoryLocation: 'location'
      repositoryProjectId: 'projectId'
      sourcePath: 'sourcePath'
      modulePath: 'appPath'
      moduleVersion: 'version'

    Ersetzen Sie die folgenden Werte:

    • repositoryName: der Name Ihres Go-Repositorys in Artifact Registry.
    • location: der Speicherort für Ihr Repository in Artifact Registry.
    • projectId: die ID des Google Cloud -Projekts, das Ihr Artifact Registry-Repository enthält.
    • sourcePath: der Pfad zur go.mod-Datei im Arbeitsbereich des Builds.
    • appPath: der Pfad zu Ihrer verpackten Anwendung.
    • version: Die Versionsnummer Ihrer Anwendung, formatiert in Zahlen und Punkten wie v1.0.1.

  3. Optional: Provenienzgenerierung aktivieren

    Cloud Build kann überprüfbare Supply-chain Levels for Software Artifacts (SLSA)-Build-Herkunftsmetadaten generieren, um Ihre Continuous Integration-Pipeline zu schützen.

    Fügen Sie requestedVerifyOption: VERIFIED dem Abschnitt options in Ihrer Konfigurationsdatei hinzu, um die Generierung von Herkunftsnachweisen zu aktivieren.

    Nach Abschluss des Builds können Sie Repository-Details in Artifact Registry aufrufen.

    Sie können auch Metadaten zur Build-Herkunft ansehen und die Herkunft validieren.

  4. Testlogs in Cloud Storage speichern: Sie können Cloud Build so konfigurieren, dass alle Testlogs in Cloud Storage gespeichert werden. Geben Sie dazu einen vorhandenen Bucket-Speicherort und einen Pfad zu den Testlogs an.

    Mit dem folgenden Build-Schritt werden die Testlogs, die Sie in der JUNIT-XML-Datei gespeichert haben, in einem Cloud Storage-Bucket gespeichert:

    # Save test logs to Google Cloud Storage
artifacts:
  objects:
    location: gs://$_BUCKET_NAME/
    paths:
      - ${SHORT_SHA}_test_log.xml

    Das folgende Snippet zeigt die vollständige Build-Konfigurationsdatei für die vorherigen Schritte:

      steps:
    # Run tests and save to file
    - name: golang:1.23
      entrypoint: /bin/bash
      args:
        - -c
        - |
          go install github.com/jstemmer/go-junit-report/v2@latest
          2>&1 go test -timeout 1m -v ./... | /go/bin/go-junit-report -set-exit-code -iocopy -out ${SHORT_SHA}_test_log.xml

  # Store golang modules in Google Artifact Registry
  artifacts:
    goModules:
      - repositoryName: 'repositoryName'
        repositoryLocation: 'location'
        repositoryProjectId: 'projectId'
        sourcePath: 'sourcePath'
        modulePath: 'appPath'
        moduleVersion: 'version'

  5. Starten Sie den Build mit der gcloud CLI oder erstellen Sie einen Build-Trigger:

    gcloud

    Führen Sie den folgenden Befehl aus und verwenden Sie --substitutions, um die Ersetzungsvariablen anzugeben, die in cloudbuild.yaml verwendet werden:

    gcloud builds submit --region=us-west2 --config=cloudbuild.yaml \
    --default-buckets-behavior=REGIONAL_USER_OWNED_BUCKET \
    --service-account=projects/PROJECT_ID/serviceAccounts/cloud-build-go@PROJECT_ID.iam.gserviceaccount.com \
    --substitutions=_AR_REPO_NAME="_AR_REPO_NAME",_BUCKET_NAME="_BUCKET_NAME",SHORT_SHA="SHORT_SHA"

    Ersetzen Sie Folgendes:

    • _AR_REPO_NAME: der Name Ihres Artifact Registry-Repositorys

    • _BUCKET_NAME: Der Name Ihres Cloud Storage-Bucket für Testlogs.

    • SHORT_SHA: ein kurzer generischer Textstring, z. B. „manual“. SHORT_SHA-Werte werden automatisch für Builds eingefügt, die durch Trigger aufgerufen werden. Sie werden jedoch nicht bereitgestellt, wenn ein Build über die gcloud CLI eingereicht wird.

    Build-Trigger

    Folgen Sie der Anleitung unter Build-Trigger erstellen. Im Feld Substitutionsvariablen müssen Sie auch den Namen Ihres Artifact Registry-Repositorys und den Namen Ihres Cloud Storage-Buckets für Testlogs angeben.

Nächste Schritte