Build schlägt im Quellenschritt fehl

Nachdem Sie einen Build erstellt und ausgeführt haben, wird der Build nicht erfolgreich ausgeführt, und Sie erhalten eine Nachricht, dass der Build im Quellenschritt fehlschlägt.

Wenn Sie eine Nachricht empfangen, dass der Quellenschritt während eines Builds fehlschlägt, überprüfen Sie die Protokolle des Builds, um die eigentliche Ursache des Problems zu ermitteln.

Beispiel für eine Fehlernachricht

Summary:  Failed to execute build run
Status:   Failed
Reason:   buildrun step step-source-default failed in pod <BUILDRUN_NAME>-zvcc9-pod-trsq2, for detailed information: ibmcloud ce buildrun logs -n <BUILDRUN_NAME>

Führen Sie den Befehl ibmcloud ce buildrun logs aus. Konzentrieren Sie sich auf die Protokolle für den fehlgeschlagenen Schritt.

ibmcloud ce buildrun logs -n <BUILDRUN_NAME>

[...]
<BUILDRUN_NAME>-zvcc9-pod-trsq2/step-source-default:
{"level":"info","ts":1625217529.370393,"logger":"git","msg":"ssh","path":"/usr/bin/ssh","version":"OpenSSH_8.0p1, OpenSSL 1.1.1g FIPS  21 Apr 2020"}
{"level":"info","ts":1625217529.3847454,"logger":"git","msg":"git","path":"/usr/bin/git","version":"git version 2.27.0"}
{"level":"info","ts":1625217529.3940003,"logger":"git","msg":"git-lfs","path":"/usr/bin/git-lfs","version":"git-lfs/2.11.0 (GitHub; linux amd64; go 1.14.4)"}
{"level":"debug","ts":1625217529.3940916,"logger":"git","msg":"/usr/bin/git clone --quiet --no-tags --branch main --depth 1 --single-branch -- https://github.com/IBM/CodeEngineX /workspace/source"}
{"level":"error","ts":1625217529.58695,"logger":"git","msg":"git command failed","command":"/usr/bin/git clone --quiet --no-tags --branch main --depth 1 --single-branch -- https://github.com/IBM/CodeEngineX /workspace/source","output":"fatal: could not read Username for 'https://github.com': terminal prompts disabled","error":"fatal: could not read Username for 'https://github.com': terminal prompts disabled (exit code 128)","stacktrace":"main.git\n\tgithub.com/shipwright-io/build/cmd/git/main.go:324\nmain.clone\n\tgithub.com/shipwright-io/build/cmd/git/main.go:277\nmain.runGitClone\n\tgithub.com/shipwright-io/build/cmd/git/main.go:115\nmain.Execute\n\tgithub.com/shipwright-io/build/cmd/git/main.go:98\nmain.checkAndRun\n\tgithub.com/shipwright-io/build/cmd/git/main.go:90\nmain.main\n\tgithub.com/shipwright-io/build/cmd/git/main.go:70\nruntime.main\n\truntime/proc.go:204"}
{"level":"error","ts":1625217529.587297,"logger":"git","msg":"program failed with an error","error":"fatal: could not read Username for 'https://github.com': terminal prompts disabled (exit code 128)","stacktrace":"main.Execute\n\tgithub.com/shipwright-io/build/cmd/git/main.go:100\nmain.checkAndRun\n\tgithub.com/shipwright-io/build/cmd/git/main.go:90\nmain.main\n\tgithub.com/shipwright-io/build/cmd/git/main.go:70\nruntime.main\n\truntime/proc.go:204"}
[...]

Der Fehlertext weicht abhängig von den vorliegenden Fehlern ab. In der folgenden Tabelle werden der Fehlertext und die möglichen eigentlichen Fehlerursachen für dieses Szenario beschrieben.

Fehlertexte und eigentliche Ursachen für fehlgeschlagenen Schritt für Git-Quelle
Fehlernachricht enthält	Mögliche eigentliche Ursachen
`terminal prompts disabled`	Das Repository ist nicht vorhanden. Die Quellen-URL wurde über das HTTPS-Protokoll bereitgestellt, aber das Repository ist privat und erfordert daher das SSH-Protokoll. Das falsche Protokoll wurde verwendet.
`Host key verification failed`	Die Quellen-URL wurde über das SSH-Protokoll bereitgestellt, aber es wurde kein geheimer Schlüssel angegeben. Das falsche Protokoll wurde verwendet oder ein geheimer Schlüssel hat gefehlt oder war falsch.
`Permission denied (publickey)`	Die Quellen-URL wurde über das SSH-Protokoll angegeben, aber ein geheimer Schlüssel fehlt oder ist falsch.
`Couldn't find remote ref`	Die im Build angegebene Revision (Verzweigungsname, Tagname, Commit-ID) ist nicht vorhanden.
`Your SSH key has expired.`	-Der SSH-Schlüssel ist abgelaufen.

Versuchen Sie eine der folgenden Lösungen.

Unabhängig davon, ob Sie Ihren Build in der Konsole oder in der CLI ausführen, verwenden Sie die CLI zur Fehlerbehebung bei Problemen mit Ihrem Build.

Führen Sie den Befehl ibmcloud ce buildrun get --name BUILDRUN_NAME aus, um die Details zu Ihrer Buildausführung anzuzeigen.
Überprüfen Sie den Wert für Reason in der Befehlsausgabe.

Nachdem Sie die Protokolle überprüft und mögliche Grundursachen identifiziert haben, können Sie das Problem mit den folgenden Maßnahmen beheben.

Problemlösung für nicht vorhandenes Repository beim Build

Verwenden Sie die folgenden Befehle, um einen vorhandenen Build so zu aktualisieren, dass von ihm die Git-Repositoryquelle verwiesen wird, und übergeben Sie die Buildausführung.

Verwenden Sie den Befehl ibmcloud ce build update, um die Buildkonfiguration zu aktualisieren. Beispiel:
```
ibmcloud ce build update --name <BUILD_NAME> --source <GIT_REPO>
```
Verwenden Sie den Befehl ibmcloud ce buildrun submit, um eine neue Buildausführung zu übergeben. Für den Befehl buildrun submit müssen Sie die Option --build angeben, um den Namen der Buildkonfiguration anzugeben. Optional können Sie auch die Option --name angeben, um den Namen für diese Buildausführung anzugeben. Wenn Sie die Option --name angeben, stellen Sie sicher, dass Sie für die Buildausführung einen anderen Namen als den Namen der fehlgeschlagenen Buildausführung verwenden; stellen Sie alternativ sicher, dass die fehlgeschlagene Buildausführung mit dem Befehl ibmcloud ce buildrun delete gelöscht wurde. Beispiel:
```
ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
```

Problemlösung für falsches Protokoll oder fehlenden geheimen Schlüssel beim Build

Die URL für ein Git-Repository kann mithilfe des HTTPS- oder SSH-Protokolls angegeben werden. GitHub und GitLab bieten eine Möglichkeit, das URL-Format in der Git-Benutzerschnittstelle zu wechseln. Für das HTTPS-Protokoll ist keine Authentifizierung erforderlich, es kann aber nur verwendet werden, wenn das Repository öffentlich ist. Bei privaten Repositorys müssen Sie das SSH-Protokoll verwenden und einen geheimen Schlüssel für das Repository bereitstellen. Repositorys in einer GitHub Enterprise-Konfiguration können zwar öffentlich sein, für sie ist aber eine Authentifizierung erforderlich; diese GitHub Enterprise-Repositorys können auch nur mithilfe eines SSH-Protokolls verwendet werden.

Für öffentliche Repositorien

Wenn der Fehler für ein öffentliches Repository aufgetreten ist, aktualisieren Sie den vorhandenen Build, um die HTTPS-URL des Git-Repositorys zu verwenden, und führen Sie den Build aus.

Verwenden Sie den Befehl ibmcloud ce build update, um die Buildkonfiguration so zu aktualisieren, dass die HTTPS-URL des Git-Repositorys verwendet wird. Beispiel:
```
ibmcloud ce build update --name <BUILD_NAME> --source <GIT_REPO>
```
Verwenden Sie den Befehl ibmcloud ce buildrun submit, um eine neue Buildausführung zu übergeben. Für den Befehl buildrun submit müssen Sie die Option --build angeben, um den Namen der Buildkonfiguration anzugeben. Optional können Sie auch die Option --name angeben, um den Namen für diese Buildausführung anzugeben. Wenn Sie die Option --name angeben, stellen Sie sicher, dass Sie für die Buildausführung einen anderen Namen als den Namen der fehlgeschlagenen Buildausführung verwenden; stellen Sie alternativ sicher, dass die fehlgeschlagene Buildausführung mit dem Befehl ibmcloud ce buildrun delete gelöscht wurde. Beispiel:
```
ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
```

Für private Repositorien

Wenn der Fehler für ein privates Repository aufgetreten ist, erstellen Sie einen geheimen SSH-Schlüssel und verwenden Sie das SSH-Protokoll. Ein geheimer SSH-Schlüssel enthält die Berechtigungsnachweise für den Zugang zum privaten Repository, das den Quellcode zum Erstellen Ihres Container-Image enthält. Ein geheimer SSH-Schlüssel wird auch als geheimer Repositoryzugriffsschlüssel für Git verwendet. Der geheime SSH-Schlüssel enthält einen privaten Schlüssel, während der entsprechende öffentliche Schlüssel beim Repository-Provider Git gespeichert wird. Weitere Informationen zum Erstellen eines Schlüsselpaars und zum Speichern des öffentlichen Teils in GitHub oder GitLab finden Sie unter Auf private Code-Repositorys zugreifen. Es ist wichtig, dass die Datei mit dem privaten Schlüssel nicht mit einer Kennphrase verschlüsselt wird, bevor Sie sie in Code Engine hochladen können. Das Format der Datei mit dem privaten Schlüssel kann variieren; daher kann nur schwer eingeschätzt werden, ob die Datei verschlüsselt ist. Je nach Version des Tools ssh-keygen, mit der das Schlüsselpaar erstellt wurde, enthält die Datei möglicherweise einen der folgenden Header:

Wenn die Datei mit -----BEGIN RSA PRIVATE KEY----- beginnt, verwendet sie das PEM-Format und wurde mit einer älteren Version ssh-keygen erstellt. Falls die Datei mit einer Kennphrase verschlüsselt ist, enthält sie in der Regel eine Zeile wie Folgende: Proc-Type: 4,ENCRYPTED.
Wenn die Datei mit -----BEGIN OPENSSH PRIVATE KEY----- beginnt, wurde sie mit einer neueren Version von ssh-keygen erstellt. Führen Sie den Befehl ssh-keygen -p -f <ID_FILE> aus, um zu überprüfen, ob er mit einer Kennphrase verschlüsselt ist.
```
ssh-keygen -p -f <ID_FILE>   
    Enter old passphrase:
```
```
ssh-keygen -p -f <ID_FILE>
    Key has comment '<COMMENT>'
Enter new passphrase (empty for no passphrase):
```
Sie können den Befehl mit der Tastenkombination Ctrl+C beenden. Falls der Befehl die alte Kennphrase erforderlich macht (1. Beispiel), war die ursprüngliche Datei verschlüsselt. Andernfalls wird direkt die Kennphrase der neuen Datei angefordert (2. Beispiel).

Führen Sie zum Entschlüsseln einer verschlüsselte Datei mit privatem Schlüssel den folgenden Befehl aus und lassen Sie die neue Kennphrase leer:
```
$ ssh-keygen -p -f <ID_FILE>

Enter old passphrase: <PASSPHRASE>
Key has comment '<COMMENT>'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.
```
Dieser Befehl ändert die Datei mit dem privaten Schlüssel. Wenn Sie Ihre verschlüsselte Version beibehalten müssen, erstellen Sie zuerst eine Kopie.

Um einen geheimen SSH-Schlüssel zu erstellen und das SSH-Protokoll zu verwenden,

Führen Sie den Befehl ibmcloud ce secret create --format ssh aus. Ein geheimer SSH-Schlüssel wird auch als geheimer Repositoryzugriffsschlüssel für Git verwendet. Von SSH_KEY_PATH muss auf die Datei mit dem privatem Schlüssel verwiesen werden, der mit dem öffentlichen Schlüssel in Ihrem Konto oder dem Bereitstellungsschlüssel im Repository identisch ist. Dieser Befehl erfordert einen Namen und einen Schlüsselpfad und lässt auch weitere optionale Argumente zu, wie z. B. den Pfad zur Datei für bekannte Hosts. Wenn Sie die Option --known-hosts-path angeben, schließen Sie den Host Ihres Git-Repositorys, z. B. github.com oder gitlab.com, in Ihre bekannte Hostdatei ein. Weitere Informationen finden Sie unter Auf private Code-Repositorys zugreifen.
```
ibmcloud ce secret create --format ssh --name <GIT_REPO_SECRET> --key-path <SSH_KEY_PATH> --known-hosts-path  <PATH_TO_KNOWN_HOSTS_FILE>
```
Verwenden Sie den Befehl ibmcloud ce build update, um die Buildkonfiguration so zu aktualisieren, dass die SSH-URL des Git-Repositorys verwendet und auf den geheimen SSH-Schlüssel <GIT_REPO_SECRET> verwiesen wird. Beispiel:
```
ibmcloud ce build update --name <BUILD_NAME> --source <GIT_REPO> --git-repo-secret <GIT_REPO_SECRET>
```
Geben Sie im vorherigen Beispiel die SSH-URL an, indem Sie das Präfix git@ für Ihre Quelle verwenden, z. B. --source git@github.com:IBM/CodeEngine.git.

Problemlösung für eine falsche Revision beim Build

Von einer Buildkonfiguration wird das Quellenrepository unter Verwendung der URL und optional einer Revision angegeben. Bei der Revision kann es sich entweder um den Namen einer Verzweigung oder eines Tags handeln oder um eine Commit-ID. Standardmäßig wird der Zweig main erstellt. Überprüfen Sie die Fehlernachricht auf Informationen, aus denen hervorgeht, dass etwas nicht vorhanden ist, was angegeben war.

Verwenden Sie den Befehl ibmcloud ce build update, um die Buildkonfiguration so zu aktualisieren, dass eine korrekte Revision (oder Festschreibung) verwendet wird. Beispiel:
```
ibmcloud ce build update --name <BUILD_NAME> --commit <COMMIT>
```
Verwenden Sie den Befehl ibmcloud ce buildrun submit, um eine neue Buildausführung zu übergeben. Für den Befehl buildrun submit müssen Sie die Option --build angeben, um den Namen der Buildkonfiguration anzugeben. Optional können Sie auch die Option --name angeben, um den Namen für diese Buildausführung anzugeben. Wenn Sie die Option --name angeben, stellen Sie sicher, dass Sie für die Buildausführung einen anderen Namen als den Namen der fehlgeschlagenen Buildausführung verwenden; stellen Sie alternativ sicher, dass die fehlgeschlagene Buildausführung mit dem Befehl ibmcloud ce buildrun delete gelöscht wurde. Beispiel:
```
ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
```

Auflösung für einen abgelaufenen SSH-Schlüssel während der Erstellung

Wenn Sie einen SSH-Schlüssel verwenden, um eine Verbindung zu Ihrem Quellenrepository herzustellen, und Sie einen Fehler erhalten, der darauf hinweist, dass der SSH-Schlüssel abgelaufen ist, müssen Sie die Einstellungen für den SSH-Schlüssel überprüfen, den Sie als geheimen Schlüssel für den Zugriff auf das Code-Repository im fehlgeschlagenen Build verwenden.

Sie müssen wissen, wie der SSH-Schlüssel erstellt wurde, ob er für einen bestimmten Benutzer erstellt wurde oder ob der SSH-Schlüssel ein Git-Implementierungsschlüssel für das Repository ist. Möglicherweise wurde ein Verfallsdatum für den Schlüssel angegeben. Das Festlegen eines Ablaufs für einen Schlüssel ist eine Funktion von GitLab.

IBM Cloud® Continuous Delivery basiert auf GitLab. Weitere Informationen finden Sie unter Continuous Delivery Git-Repositorys und Problemverfolgung.

Führen Sie die folgenden Aktionen aus, um diesen Fehler zu beheben.

Wenn Sie den in Code Engineverwendeten SSH-Schlüssel kennen, aktualisieren Sie den Bereitstellungs-oder Benutzerschlüssel mit demselben öffentlichen SSH-Schlüssel in GitLab. Verwenden Sie bei der Aktualisierung kein Ablaufdatum und keine Aktualisierung auf ein anderes Ablaufdatum. Da Sie denselben SSH-Schlüssel in Ihrem geheimen Schlüssel in Code Engineverwenden, müssen Sie den geheimen Schlüssel für den Code-Repository-Zugriff in Code Enginenicht aktualisieren.
Aktualisieren Sie den geheimen Schlüssel für den Zugriff auf das Code-Repository für die Verwendung des neuen SSH-Schlüssels.
1. Verwenden Sie in GitLabden öffentlichen SSH-Schlüssel, um einen Bereitstellungsschlüssel oder einen Benutzerschlüssel zu erstellen.
2. Aktualisieren Sie in Code Engineden geheimen Schlüssel für den Zugriff auf das Code-Repository, sodass der neue private SSH-Schlüssel verwendet wird.
  
  Angenommen, Sie möchten den geheimen Schlüssel für den Zugriff auf das mysecret-ssh-Code-Repository aktualisieren. Verwenden Sie den Befehl ibmcloud ce secret update --format ssh, um einen geheimen Schlüssel für die Authentifizierung Ihres Git-Repositorys zu aktualisieren.
```
ibmcloud ce secret update --format ssh --name mysecret-ssh --key-path $HOME/.ssh/id_rsa --known-hosts-path $HOME/.ssh/known_hosts
```

Weitere Informationen zum Arbeiten mit SSH-Schlüsseln für ein Code-Repository finden Sie unter Zugriff auf private Code-Repositorys.