Ich habe eine Toolchain erstellt und der Delivery Pipeline-Service wird nicht initialisiert. Warum wird die Initialisierung der Pipeline nicht ausgeführt?

Möglicherweise müssen Sie die GitHub-Toolintegration erneut konfigurieren und speichern.

Die GitHub-Tool-Integration in Ihrer Toolchain ist möglicherweise falsch konfiguriert; dadurch wird verhindert, dass die Pipeline-Initialisierung ausgeführt wird.

Es ist ein Problem aufgetreten, das dazu geführt hat, dass die GitHub-Toolintegration fehlgeschlagen ist.

Konfigurieren und speichern Sie die GitHub-Toolintegration erneut:

1. Klicken Sie in der Konsole IBM Cloud auf das Menüsymbol > Plattformautomatisierung > Toolchains. Klicken Sie auf der Seite Toolchains auf die Toolchain, die Sie erstellt haben, um die Übersichtsseite zu öffnen. Klicken Sie alternativ auf der Seite mit den App-Details in Ihrer App auf den Toolchainnamen.
2. Suchen Sie auf der Übersichtsseite der Toolchain auf der Karte Repositorys nach der GitHub-Toolintegration.
3. Klicken Sie auf das Menü, um auf die Konfigurationsoptionen zuzugreifen, aktualisieren Sie die Einstellungen und klicken Sie auf Integration speichern.
4. Klicken Sie auf der Karte Delivery Pipelines auf die Toolintegration Delivery Pipeline, um die Pipelinekonfiguration anzuzeigen.

Warum wird die Pipeline nicht ordnungsgemäß erstellt, wenn ich eine Toolchain aus meiner eigenen Vorlage erstelle?

Möglicherweise fehlen in Ihrer Pipeline aufgrund eines Fehlers in Ihrer 'pipeline.yaml'-Definition Ressourcen wie Jobs und Phasen.

Wenn ich versuche, eine Toolchain aus einer eigenen Vorlage zu erstellen, wird mir die folgende Fehlernachricht auf der Seite 'Pipeline' angezeigt:

This pipeline was created, but might be missing jobs, stages, or other resources. You can use this pipeline, or if you prefer, you can delete it and create another pipeline.

Dieses Problem wird in der Regel durch einen Fehler in Ihrer 'pipeline.yaml'-Definition verursacht.

Verwenden Sie eine der folgenden Methoden, um diesen Fehler zu debuggen:

• Verwenden Sie die Pipelinebenutzerschnittstelle, um eine Beispielpipeline zu erstellen, die die Pipeline repliziert, die Sie mit Ihrer Vorlage zu erstellen versuchen. Hängen Sie /yaml an die Pipeline-URL an, um eine identische 'pipeline.yaml'-Datei zu generieren, die Sie verwenden können, um nach offensichtlichen Unterschieden zu suchen. Beispiel: https://cloud.ibm.com/devops/pipelines/<your pipeline id>/yaml?env_id=<your region>.

• Verwenden Sie Mechanismus zur Erstellung von Toolchains ohne GUI. Öffnen Sie auf der Seite Toolchain erstellen den Debugger und werten Sie den Ausdruck window.Testflags = {nocreate: 1} aus. Wenn Sie in diesem Modus auf Toolchain erstellen klicken, wird die Toolchain nicht erstellt. Stattdessen werden die Informationen, die an die API übergeben werden, an die Konsole zurückgegeben, wo Sie sie überprüfen können.

Warum wird beim Versuch, eine Pipeline auszuführen, eine Fehlernachricht bezüglich des Zugriffs auf das Git-Repository ausgegeben?

Die Pipeline verwendet ein Zugriffstoken für das Klonen des Git-Repositorys. Wenn das Zugriffstoken nicht gültig ist, kann der Eigner der Git-Integration nicht auf das Git-Repository zugreifen.

Zu den unterstützten Git-Integrationen gehören die GitHub-, GitLab-, Bitbucket- und Git Repos and Issue Tracking-Toolintegrationen.

Beim Versuch, eine Pipeline auszuführen, wird die folgende Fehlernachricht ausgegeben:

The access token for this git repository is no longer valid. Please reconfigure the git integration to ensure the integration owner has access to this repository.

Das Zugriffstoken, das die Pipeline zum Klonen des Git-Repositorys verwendet, ist nicht mehr gültig. Dieses Problem tritt möglicherweise auf, weil das Token inaktiviert wurde. Das Zugriffstoken kann auch ungültig sein, wenn der Eigner der Git-Integration aufgrund von Berechtigungsänderungen mehr über Zugriff auf das Repository verfügt.

Konfigurieren Sie die Git-Integration erneut und speichern Sie sie:

1. Klicken Sie in der Konsole IBM Cloud auf das Menüsymbol > Plattformautomatisierung > Toolchains. Klicken Sie auf der Seite Toolchains auf die Toolchain mit der Git-Integration, die aktualisiert werden soll, um die zugehörige Übersichtsseite zu öffnen. Klicken Sie alternativ auf der Seite mit den App-Details in Ihrer App auf den Toolchainnamen.
2. Suchen Sie auf der Übersichtsseite der Toolchain auf der Karte Repositorys nach der Toolintegration für Git.
3. Klicken Sie auf das Menü, um auf die Konfigurationsoptionen zuzugreifen, wählen Sie das berechtigte Git-Konto für den Git-Integrationseigner aus und klicken Sie auf Integration speichern.
4. Führen Sie die Pipeline erneut aus.

Ich habe eine Bereitstellung in Kubernetes mithilfe von Delivery Pipeline versucht. Warum wird mir ein Fehler wegen eines ungültigen Objekts gemeldet?

Das 1.0-Pipeline-Basisimage enthält kubectl v1.14.2. Es könnte ein Fehler gemeldet werden, wenn der Kubernetes-Cluster, zu dem Sie eine Verbindung herstellen, eine aktuellere Version von Kubernetes ausführt.

Wenn ich mithilfe von Delivery Pipeline eine Bereitstellung in Kubernetes versuche, wird die folgende Fehlernachricht angezeigt:

error:SchemaeError(io.k8s.api.core.v1.SecretProjection): invalid object doesn't have additional properties

In der Regel wird dieses Problem dadurch verursacht, dass die Version des kubectl-Befehls in Ihrem Pipeline-Basisimage nicht mit der im Cluster ausgeführten Version von Kubernetes kompatibel ist.

Verwenden Sie eine der folgenden Methoden, um dieses Problem zu lösen:

• Verwenden Sie eine aktuellere Pipeline-Basisimageversion, die, wenn erstellt, die aktuell veröffentlichte Version von kubectl enthält. Informationen zum Angeben der neuesten Imageversion finden Sie unter Imageversion angeben.

• Stellen Sie sicher, dass Ihr Pipelinejob die korrekte Version von kubectl ausführt. Fügen Sie zum Beispiel die folgenden Zeilen am Anfang Ihres Pipelinejobs hinzu, um kubectl v1.14.2 auszuführen:

  curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.14.2/bin/linux/amd64/kubectl
  chmod +x ./kubectl
  sudo mv ./kubectl /usr/local/bin/kubectl

Wenn Sie kubectl v1.14.2 von einem 1.0-Pipeline-Basisimage ausführen, ist die Option 'sudo' nicht verfügbar. Ersetzen Sie die 'sudo'-Zeile durch den folgenden Befehl, um kubectl Ihrem Pfad hinzuzufügen:

   mkdir ~/.bin && export PATH=~/.bin:$PATH && mv ./kubectl ~/.bin/kubectl

Weitere Informationen über den Zugriff auf die genaue Version von kubectl, die Sie benötigen, finden Sie unter Installieren und Einrichten von kubectl.

Warum wird beim Ausführen einer Pipeline der Fehler 403 von IBM Cloud Container Registry ausgegeben?

Die IBM Cloud® Container Registry-Pipeline überträgt Images mithilfe von Push- und Pull-Operationen an bzw. von IBM Cloud Container Registry. Der IBM Cloud Container Registry Serviceplan bestimmt die Menge an Speicherplatz und Datenverkehr, die Sie für Ihre privaten Bilder nutzen können.

Beim Versuch, eine Pipeline auszuführen, wird die folgende Fehlernachricht ausgegeben:

Failed to pull image "us.icr.io/sdl-ns/achilles:a100-p203-6-20190717161046-78fbc8a3a0fbc8571d887e57499642e0326e7035": rpc error: code = Unknown desc = failed to pull and unpack image "us.icr.io/sdl-ns/achilles:a100-p203-6-20190717161046-78fbc8a3a0fbc8571d887e57499642e0326e7035": failed to copy: httpReaderSeeker: failed open: unexpected status code https://us.icr.io/v2/sdl-ns/achilles/blobs/sha256:365b19774a508fd998bc636981cb9869a406786ad811e51937fa6fb089c86005: 403 Forbidden

Möglicherweise wurden die Grenzwerte für Pull-Datenverkehrskontingente überschritten, wodurch das Abrufen des Docker-Images verhindert wird.

Überprüfen Sie die Grenzwerte für Kontingente und Nutzung für das Speichern und Abrufen von Images. Geben Sie belegten Speicherplatz frei und ändern Sie die Servicepläne oder die Grenzwerte für Kontingente, um die angegebenen Größenbeschränkungen einzuhalten.

Warum ist die Kompilierung einer App in einem einzelnen Pipeline-Job fehlschlagen?

Für die Erstellung einer App in einem einzelnen Pipeline-Job sind 4 GB Hauptspeicher (nicht Dateispeicher) erforderlich.

Beim Kompilieren einer App in einem einzelnen Pipeline-Job schlägt der Build mit einem unerwarteten Fehler fehl.

Für die Kompilierung einer App in einem einzelnen Pipeline-Job sind mehr als 4 GB Hauptspeicher erforderlich.

Gehen Sie wie folgt vor, um die App in einem einzelnen Pipeline-Job zu erstellen:

1. Erstellen Sie einen privaten Worker in IBM Cloud® Continuous Delivery Pipeline.
2. Konfigurieren Sie den Build-Job so, dass er den privaten Worker verwendet.

Warum ist keine Delivery Pipeline-Kommunikation durch eine Firewall möglich?

Die Firewallkonfiguration verhindert, dass Delivery Pipeline mit Umgebungen kommuniziert, die sich hinter einer Firewall befinden.

Bein Versuch, Delivery Pipeline zu verwenden, ist keine Kommunikation durch die Firewall möglich.

Die Firewall muss so konfiguriert werden, dass sie die Kommunikation zwischen Delivery Pipeline und Umgebungen zulässt, die sich hinter einer Firewall befinden.

Sie können die Firewallkonfigurationen so aktualisieren, dass Delivery Pipeline auf Ressourcen zugreifen kann, die sich hinter der Firewall befinden. Verwenden Sie die CIS Zulassungsliste und die Subnetzbereiche für Ihre spezifische Region.

Warum habe ich eine Benachrichtigung darüber erhalten, dass Repository-Referenzen in meinen Pipeline-Auslösern oder -Definitionen festgelegt wurden?

Sie haben Repository-Integrationen aus Ihrer Toolchain geändert, hinzugefügt, oder entfernt, wodurch Verweise auf die Integrationen, die in den Pipelineauslösern oder -definitionen gespeichert sind, ungültig wurden.

Wenn ich Repositoryintegrationen aus meiner Toolchain ändere, hinzufüge, oder entferne, werden Warnsymbole und Validierungsfehler in meiner Pipelinekonfiguration angezeigt.

In bestimmten Szenarien können Verweise auf diese Integrationen, die in den Pipelineauslösern oder -definitionen gespeichert sind, ungültig werden, wenn Sie Repository-Integrationen in Ihrer Toolchain ändern, hinzufügen, oder entfernen.

Wenn eine übereinstimmende Repository-Integration in der Toolchain gefunden wird, versucht die Pipeline, diese Referenzen automatisch zu aktualisieren, um die ungültigen Integrationsreferenzen zu korrigieren. Auf der Benutzeroberfläche wird eine Benachrichtigung mit einer der folgenden Meldungen angezeigt:

• Repository reference fixed in the following triggers: [list of triggers]
• Repository reference fixed in the following definitions: [list of definitions]

Wenn eine dieser Benachrichtigungen angezeigt wird, aber keine Warnungen oder Fehler in der Konfiguration angezeigt werden, ist keine weitere Aktion erforderlich. Wenn weiterhin Warnungen oder Fehler angezeigt werden, müssen Sie möglicherweise den Auslöser oder die Definition erneut aktualisieren bzw. erstellen.

Warum kommt es in meiner Pipeline zu einer Zeitüberschreitung, wenn sie versucht, eine Verbindung zu IBM Cloud Object Storage privaten Endpunkten herzustellen?

Wenn Sie eine Pipeline ausführen, laufen Anfragen an den IBM Cloud Object Storage, die einen privaten Endpunkt verwenden, ohne Antwort ab. Diese Zeitüberschreitung kann zum Ausfall der Pipeline führen.

IBM Cloud Object Storage Private Endpunkte sind nicht von allen IBM Cloud Clustertypen aus zugänglich. Private IBM Cloud Object Storage Endpunkte sind von privaten Workern, die auf Clustern innerhalb einer IBM Cloud® Virtual Private Cloud (VPC) ausgeführt werden, nicht zugänglich.

Ersetzen Sie alle s3.private.*IBM Cloud Object Storage Endpunkte durch s3.direct.* Endpunkte. s3.direct.* Endpunkte sind direkte Endpunkte, die mit IBM Cloud Object Storage von jedem IBM Cloud Clustertyp kommunizieren.

Warum schlägt meine Pipeline mit einem Fehler fehl, der sich auf sichere Eigenschaften bezieht?

PipelineRuns schlägt mit einem Fehler fehl, wenn eine der sicheren Eigenschaften in der Pipeline zu Beginn der Pipeline-Ausführung nicht aufgelöst werden kann.

Pipelines, die keinen geheimen Wert aus einem Geheimnisspeicher oder aus Secrets Manager, Key Protect oder HashiCorp Vault abrufen können, schlagen mit einer Fehlermeldung fehl, die angibt, welche Eigenschaften nicht aufgelöst werden können. Auflösungsfehler können auftreten, auch wenn die Eigenschaften nicht direkt in der ausgelösten Ausführung verwendet werden. Es können beispielsweise Auflösungsfehler auftreten, wenn der Pfad zum geheimen Schlüssel im Speicher nicht mehr gültig ist, auf den Speicher für geheime Schlüssel nicht mehr zugegriffen werden kann oder wenn Berechtigungsprobleme vorliegen.

Wenn Ihre Pipelines sichere Eigenschaften enthalten, die derzeit nicht aufgelöst werden können, aktualisieren Sie diese Eigenschaften, um auf gültige, abrufbare Geheimnisse zu verweisen, die sich in Secrets Manager, Key Protect oder HashiCorp Vault befinden.

Stellen Sie sicher, dass Ihre Pipeline nur die sicheren Eigenschaften angibt, die für den erfolgreichen Abschluss eines ausgelösten PipelineRun s als Pipeline-Triggereigenschaften erforderlich sind, und nicht als Umgebungseigenschaften auf Pipelineebene. Verwenden Sie Umgebungseigenschaften auf Pipelineebene nur bei Bedarf.

Warum meldet meine Pipeline einen Fehler beim Abrufen der Pipelinedefinition?

Auf der Delivery Pipeline Seite wird ein Fehler beim Abrufen der Pipeline-Definition angezeigt. Alternativ tritt der Fehler auf, wenn versucht wird, eine PipelineRun. auszulösen.

Es gibt mehrere Gründe, warum beim Abrufen der Definition für eine Pipeline ein Fehler auftreten kann. Wenn die Definition beispielsweise in einem großen Repository definiert ist, kann die Anfrage zum Abrufen der Definition aufgrund einer Verzögerung beim Klonen des großen Repositorys vor dem Erstellen der Definition eine Zeitspanne umfassen. Ein weiteres Beispiel ist, wenn eine Definitionseingabe auf eine Verzweigung oder einen Pfad abzielt, die bzw. der nicht mehr im Repository vorhanden ist.

Versuchen Sie, das Problem mithilfe einer der folgenden Optionen zu beheben:

• Laden Sie die Seite erneut, um eine neue Anforderung zum Abrufen der Definition einzuleiten. Wenn dies wiederholt fehlschlägt, fahren Sie mit den folgenden Optionen fort.
• Überprüfen Sie, ob alle referenzierten Verzweigungen und Pfade in Ihren Definitionseingaben mit Ressourcen im Repository übereinstimmen.
• Verkleinern Sie das Repository, das Ihre Tekton-Definition enthält. Entfernen Sie nicht benötigte Dateien aus dem Repository und aktualisieren Sie .gitignore, um das Hochladen nicht benötigter Dateien auszuschließen.
• Schließen Sie nur die mindestens erforderlichen Dateien Ihrer Pipelinedefinition ein-legen Sie nicht das gesamte Repository als Ziel fest. Verschieben Sie alle Tekton-Definitionsdateien in einen Unterordner Ihres Repositorys und bearbeiten Sie dann die Definitionseingabe in Ihren Delivery Pipeline, um den Pfad auf den Unterordner zu richten. Diese Option verringert den Zeitaufwand für das Klonen der Definitionsdateien aus Ihrem Repository.
• Bei umfangreichen Tekton-Definitionen sollten Sie in Erwägung ziehen, die Definition in mehrere Ordner oder mehrere Repositories aufzuteilen. Aktualisieren Sie dann die Definitionseinträge in Ihrer Delivery Pipeline, um die erforderlichen Ordner oder Repos anzuvisieren.

Die berechnete Größenbegrenzung für die Pipelinedefinition beträgt 1 MB. Wenn beim Speichern oder Ausführen Ihrer Pipeline Fehler auftreten, müssen Sie möglicherweise die Größe Ihrer Pipelinedefinition reduzieren oder sie in mehrere Pipelines aufteilen.

Warum kann meine Pipeline keine Verbindung mit dem Cluster Red Hat OpenShift on IBM Cloud herstellen?

Pipelines, die versuchen, sich bei einem Zielcluster anzumelden, auf dem oc login die Version 4.13 und Red Hat OpenShift on IBM Cloud höher ausgeführt wird, können sich nicht anmelden.

Das Problem wird durch eine Änderung verursacht, die in der Version 4.13 von Red Hat OpenShift on IBM Cloud.

Verwenden Sie den folgenden Prozess, um das Problem zu umgehen:

ibmcloud login --apikey "${IBMCLOUD_API_KEY}" -r "${REGION}" -g "${RESOURCE_GROUP}"
ibmcloud oc cluster config --cluster "${CLUSTER_NAME}" --endpoint private --admin
kubectl config current-context
oc version
oc get pods -A  # To verify connection

Warum schlägt meine Pipeline beim Ausführen eines Git fehl?

Tekton Pipelines, die die Befehlsaufgabe " git-clone-repo verwenden, schlagen möglicherweise mit der folgenden Fehlermeldung fehl:

Clone was not successful. Code 128 - Retrying shortly...
fatal: destination path '.' already exists and is not an empty directory.

Das Problem ist auf eine Leistungsänderung in der Infrastruktur der öffentlich verwalteten Pipeline-Arbeiter zurückzuführen.

Gehen Sie wie folgt vor, um das Problem zu lösen:

• Suchen Sie die Tekton-Definitionen unter Einstellungen für Ihre Pipeline und finden Sie den Eintrag für " git unter Pfad. Klicken Sie zum Öffnen auf den Repository-Link. Navigieren Sie zu " git/task-clone-repo.yaml und suchen Sie dann in dieser Datei den Schritt " clone-repo. Im Tekton-Katalog finden Sie ein Beispiel für den neuesten Code.
• Fügen Sie rm -rf "lost+found" zur Definition vor dem Aufruf von git clone hinzu. Dadurch wird sichergestellt, dass das zu klonende Verzeichnis leer ist.
• Führen Sie die Pipeline erneut aus.

Warum startet meine Pipeline bei verwalteten Mitarbeitern nicht, wenn sie von einem Testkonto aus ausgeführt wird?

Klassische Pipelines, die über ein Testkonto ausgeführt werden, werden aufgrund des folgenden Fehlers nicht gestartet:

This type of account is not entitled to use managed workers. Private workers can be used instead or to gain access managed worker capability the account must be upgraded to a paid plan.

Dieses Verhalten wird durch eine Überarbeitung der Berechtigungen für Testkonten verursacht.

Ihnen stehen die folgenden Möglichkeiten zur Verfügung, um dieses Problem zu beheben:

• Führen Sie Ihre Pipelines mit Hilfe eines privaten Workers auf Ihrem eigenen Cluster aus.
• Führen Sie ein Upgrade Ihres Testkontos auf ein Nutzungsabhängige Zahlung-Konto mit einem Lite-Tarif durch.

Warum löst meine Pipeline keine Pull-Request-Ereignisse von geforketen Repositories aus?

Pipelines reagieren standardmäßig nicht auf Pull-Request-Ereignisse von geforketen Repositories

Dieses Verhalten ist beabsichtigt, um die versehentliche Ausführung von Pipelines zu verhindern.

Gehen Sie wie folgt vor, um die Ausführung von Pipelines bei Ereignissen aus geforkten Repositories zu ermöglichen:

• Tekton Pipelines: Aktivieren Sie im Git den Schalter Include pull request events from forks
• Klassische Pipelines: Aktivieren Sie auf der Registerkarte "Eingabe" der Bühnenkonfiguration den Schalter " Include pull request events from forks

Warum sehe ich manchmal ExceededNodeResources in den Pod-Ereignissen für meinen Pipeline-Lauf?

Manchmal, wenn eine Aufgabe länger als erwartet zum Starten braucht, können Meldungen ExceededNodeResources mit dem reason Wert in der Pod-Ereignisansicht der Aufgabe auf der pipelineRun Detailseite angezeigt werden.

Dies tritt häufig auf, wenn eine Aufgabe versucht, ein Volume zu verwenden, das bereits auf einem überlasteten Knoten gemountet ist. Dies kann auch vorkommen, wenn der Cluster überlastet ist und das Hochfahren eines neuen Knotens während eines automatischen Cluster-Skalierungsereignisses Zeit in Anspruch nimmt.

Bei diesen Meldungen handelt es sich wahrscheinlich um normale Betriebsmeldungen Ihres Kubernetes Clusters. Für diese Art von Nachrichten ist in der Regel kein Benutzereingriff erforderlich. Diese treten entweder auf, wenn ein Autoscaling-Ereignis eintritt und Ressourcen für die Nutzung frei werden, oder wenn Ressourcen später verfügbar werden. Die Pipeline wird also fortgesetzt, sobald der Pod eingeplant ist. Im Wesentlichen wartet die Pipeline darauf, dass die erforderlichen Ressourcen durch automatische Skalierung oder auf andere Weise verfügbar werden, so dass der Pod bereitgestellt werden kann und die Pipeline weiterläuft.

Warum treten bei der Verwendung eines Docker oder Podman Sidecars Netzwerkfehler auf?

Beim Ausführen einer Tekton-Pipeline mit einem Docker oder Podman Sidecar treten eines oder mehrere der folgenden Symptome auf:

• Zeitweise Verbindungszeitüberschreitungen
• Große Anfragen/Antworten schlagen fehl, während kleine erfolgreich sind
• Dienste funktionieren lokal einwandfrei, schlagen jedoch im Cluster fehl
• TLS handshake-Ausfälle

Es besteht eine MTU-Inkompatibilität zwischen dem Docker-Daemon und dem Host-Netzwerk. Der interne DockerPodman Daemon erstellt sein eigenes Bridge-Netzwerk mit einer Standard-MTU von 1500, aber die Netzwerkschnittstelle des Pods unterstützt aufgrund der Overlay-Kapselung möglicherweise nur 1450 Byte. Es ist diese Diskrepanz, die zu Netzwerkausfällen führt.

Aktualisieren Sie die Pipeline-Definition, um den mtu Wert für Docker wie folgt explizit festzulegen:

• Docker: com.docker.network.driver.mtu: 1400
• Podman oder podman network create --opt mtu=1400 in manchen Fällen festlegen --network=host