Pipeline-Läufe sind aufgrund der Git Ratenbegrenzung langsam

Die Pipeline-Ausführung sieht langsamer aus, Pipeline-Läufe brauchen länger, um ausgeführt und abgeschlossen zu werden.

Auch der folgende Eintrag findet sich an verschiedenen Stellen in den Protokollen:

Unable to use this tool because the git API rate limit is exceeded. Please try again in <n> minutes.

Pipelines verwenden intern Git API-Anfragen ( Git Status setzen, Issues erstellen/aktualisieren,...). Es gibt eine Höchstgrenze von Git API-Anfragen pro „ Git ”-Token pro Stunde. Wenn diese Grenze bald erreicht ist, gibt es einen internen Pipeline-Mechanismus, der die Anfragen anhält - und damit auch den Pipeline-Lauf -, um einen vorzeitigen Abbruch des Pipeline-Laufs zu verhindern. Dies kann zu lang laufenden Pipelines führen.

Um dieses Git Problem der Ratenbegrenzung zu überwinden:

1. Migrieren Sie von Git evidence locker zu COS evidence locker (auch bekannt als COS only). Siehe den entsprechenden Abschnitt in der Dokumentation IBM Cloud.
2. Verwenden Sie unterschiedliche „ Git “-Token für Pipelines und/oder Trigger.

Der Schritt "check-registry" der containerisierten Task schlägt mit einem Fehler fehl.

Die IBM Cloud-Registry bietet ein begrenztes Kontingent. Es können zu viele Images mit einer Push-Operation übertragen werden.

1. Wechseln Sie zu Images und löschen Sie die Images, die nicht benötigt werden.
2. Führen Sie die Pipeline erneut aus.

Sie können die Kontingente und die Nutzung mit dem folgenden Befehl überprüfen:

ibmcloud cr quota

Protokolle werden für Schritt nicht angezeigt

Dies ist ein Problem mit der Tekton-Umgebung.

Versuchen Sie, die Seite erneut zu laden. Laden Sie die Protokolle über die Schaltfläche zum Herunterladen herunter.

Task wurde abgebrochen, da auf das Basisimage nicht zugegriffen werden kann

Überprüfen Sie, ob Ihre Artifactory-Berechtigungsnachweise korrekt sind. Hier kann ein neues Artifactory-Token erstellt werden. Sie können einen geheimen Schlüssel manuell erstellen, indem Sie Folgendes ausführen:

kubectl create secret docker-registry mysecret \
--dry-run \
--docker-server=<artifactory-server-domain> \
--docker-username=<username> \
--docker-password=<artifactory token> \
--docker-email=<email> \
-o yaml

Es gibt eine Ausgabe ähnlich der folgenden aus:

apiVersion: v1
data:
  .dockerconfigjson: <your secret>
kind: Secret
metadata:
  creationTimestamp: null
  name: regcred
type: kubernetes.io/dockerconfigjson

Aktualisieren Sie in den Pipelineeigenschaften den Parameter artifactory-dockerconfigjson mit dem Wert .dockerconfigjson .

Weitere Informationen finden Sie in der kubectl-Dokumentation zum Erstellen eines geheimen Schlüssels(: extern).

Pipeline schlägt früh fehl

Wenn eine Pipeline in einem frühen Stadium mit der folgenden Nachricht fehlschlägt:

Pipeline could not run, resource failed to apply - Kind: "Secret", Name: "pipeline-pull-secret" ResourceError

In diesem Fall ist der Fehler in der Pipeline aufgetreten, weil sie nicht gebootet wurde. Daher sind keine Protokolle verfügbar.

Das dockerconfig.json Geheimnis, das die Bilder „ Docker “ von IBMContainer Registry abruft, das von dieser Pipeline verwendet wird, ist nicht korrekt.

Möglicherweise ist dieser geheime Schlüssel falsch oder der diesem geheimen Schlüssel zugeordnete API-Schlüssel wurde turnusmäßig gewechselt oder widerrufen.

Generieren Sie einen neuen geheimen Wert und verwenden dockerconfig.json Sie diesen dann in Ihrer Pipeline (entweder als Pipeline-Parameter oder gespeichert unter „ Secrets Manager “).

Um eine neue dockerconfig.json zu erstellen, führen Sie den folgenden Befehl aus:

kubectl create secret docker-registry my-registry-secret \
 -o json \
 --dry-run=client \
 --docker-server=icr.io \
 --docker-username=iamapikey \
 --docker-email=john-doe@ibm.com \
 --docker-password=<apikey> \
  | jq -r '.data[".dockerconfigjson"]'

Dabei steht <apikey> für Ihren IBM Cloud-Cloud-API-Schlüssel oder einen Service-ID-API-Schlüssel.

Pipeline kann keine Images aus mehreren Artifactory-Repositorys extrahieren

Die Pipeline hat erfolgreich Images aus einem Repository extrahiert, aber nicht aus einem anderen Repository.

Die Pipeline ist fehlgeschlagen, weil sie für das Extrahieren von Images aus einem einzelnen Repository konfiguriert ist.

Erstellen Sie manuell einen neuen geheimen Artifactory- dockerconfigjson-Schlüssel, um die Authentifizierung bei mehreren Repositorys zu unterstützen.

Um die Authentifizierung für das Extrahieren von Images aus mehreren Repositorys in Artifactoryzu unterstützen, generieren Sie eine neue dockerconfigjson und fügen Sie den Pipelines eine Umgebungseigenschaft des Typs artifactory-dockerconfigjson für den geheimen Schlüssel hinzu.

Das folgende Script ist ein Beispiel zum Generieren einer Artifactory dockerconfigjson, die Authentifizierungsdetails für zwei verschiedene Artifactory-Repositorys bereitstellt. Dies ist ein anpassbares Script.

CRA- oder Docker-Build schlägt aufgrund fehlender Submoduldateien fehl

Wenn eine Pipelinestufe wie CRA oder Docker build fehlschlägt, wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:

failed to calculate checksum of ref moby::...: failed to walk /var/lib/docker/tmp/buildkit-mount.../common-dev-assets/module-assets/ci: lstat ... no such file or directory

Dieser Fehler tritt auf, weil Ihr Repository Submodule von „ Git “ enthält, Pipelines jedoch standardmäßig keine Submodule klonen. Jede Pipelinestufe wird in einem eigenen Container ausgeführt und führt einen neuen Checkout des Repositorys durch, so dass die Inhalte der Submodule fehlen, sofern sie nicht explizit initialisiert werden.

Um dieses Problem zu beheben, müssen Sie sicherstellen, dass das Submodul „ Git “ in jeder Phase initialisiert wird, in der es benötigt wird. Speziell für CRA können Sie die Initialisierung des Submoduls zu Ihrem benutzerdefinierten CRA-Skript hinzufügen.

Aktualisieren Sie zum Beispiel Ihr Skript, um es einzuschließen:

git submodule update --init --recursive

Dadurch wird gewährleistet, dass das Submodul verfügbar ist, bevor der CRA-Build-Prozess läuft.