La génération échoue dans l'étape source

Une fois que vous avez créé et exécuté une génération, votre génération n'aboutit pas et vous recevez un message indiquant que la génération échoue dans l'étape source.

Si vous recevez un message indiquant que l'étape source échoue au cours d'une génération, consultez les journaux de la génération pour déterminer la cause première du problème.

Exemple de message d'erreur

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>

Exécutez la commande ibmcloud ce buildrun logs. Concentrez-vous sur les journaux de l'étape ayant échoué :

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"}
[...]

Le texte d'erreur est différent selon le problème qui s'est produit. Le tableau ci-après décrit le texte d'erreur et les causes premières potentielles pour ce scénario.

Texte d'erreur et causes premières pour l'étape de code source Git ayant échoué.
Message d'erreur	Causes premières potentielles
`terminal prompts disabled`	Le référentiel n'existe pas. L'URL source a été fournie en utilisant le protocole HTTPS, mais le référentiel est privé et nécessite par conséquent le protocole SSH. Le protocole utilisé est inapproprié.
`Host key verification failed`	L'URL source a été fournie en utilisant le protocole SSH, mais aucun secret n'a été fourni. Le protocole utilisé est inapproprié ou un secret est manquant ou incorrect.
`Permission denied (publickey)`	L'URL source a été fournie en utilisant le protocole SSH, mais un secret est manquant ou incorrect.
`Couldn't find remote ref`	La révision (nom de branche, nom de balise, ID de validation) spécifiée dans la génération n'existe pas.
`Your SSH key has expired.`	-La clé SSH a expiré.

Essayez l'une des solutions ci-après.

Que vous exécutiez votre génération depuis la console ou depuis l'interface de ligne de commande, utilisez l'interface de ligne de commande pour traiter les problèmes liés à votre génération.

Exécutez la commande ibmcloud ce buildrun get --name BUILDRUN_NAME pour afficher les détails de votre exécution de génération.
Consultez la section Reason dans la sortie de la commande.

Une fois que vous avez consulté les journaux et identifié les causes premières potentielles, utilisez les actions de résolution ci-dessous pour résoudre le problème.

Résolution d'un problème de référentiel inexistant lors de la génération

Utilisez les commandes ci-après afin de mettre à jour la génération existante pour qu'elle fasse référence à votre code source de référentiel Git et soumettez l'exécution de génération.

Utilisez la commande ibmcloud ce build update pour mettre à jour la configuration de la génération, par exemple :
```
ibmcloud ce build update --name <BUILD_NAME> --source <GIT_REPO>
```
Utilisez la commande ibmcloud ce buildrun submit pour soumettre une nouvelle exécution de génération. Pour la commande buildrun submit, vous devez spécifier l'option --build pour fournir le nom de votre configuration de génération. Vous pouvez éventuellement spécifier l'option --name pour fournir le nom de cette exécution de génération. Si vous spécifiez l'option --name, veillez à utiliser un autre nom d'exécution de génération que celui de l'exécution de génération ayant échoué, ou à supprimer l'exécution de génération ayant échoué à l'aide de la commande ibmcloud ce buildrun delete. Par exemple :
```
ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
```

Résolution d'un problème de protocole incorrect ou d'un secret manquant lors de la génération

L'URL vers un référentiel Git peut être spécifiée à l'aide du protocole HTTPS ou SSH. GitHub et GitLab fournissent un moyen de changer de format URL dans l'interface utilisateur Git. Le protocole HTTPS ne requiert aucune authentification mais ne peut être utilisé que si le référentiel est public. Pour les référentiels privés, vous devez utiliser le protocole SSH et fournir un secret pour le référentiel. Les référentiels d'une configuration GitHub Enterprise peuvent être publics mais nécessitent toujours une authentification, et ces référentiels GitHub Enterprise ne peuvent aussi être utilisés qu'en se servant du protocole SSH.

Pour les référentiels publics

Si l'échec s'est produit pour un référentiel public, mettez à jour la génération existante pour utiliser l'URL HTTPS du référentiel Git, puis exécutez la génération.

Utilisez la commande ibmcloud ce build update pour mettre à jour la configuration de génération afin d'utiliser l'URL HTTPS du référentiel Git, par exemple :
```
ibmcloud ce build update --name <BUILD_NAME> --source <GIT_REPO>
```
Utilisez la commande ibmcloud ce buildrun submit pour soumettre une nouvelle exécution de génération. Pour la commande buildrun submit, vous devez spécifier l'option --build pour fournir le nom de votre configuration de génération. Vous pouvez éventuellement spécifier l'option --name pour fournir le nom de cette exécution de génération. Si vous spécifiez l'option --name, veillez à utiliser un autre nom d'exécution de génération que celui de l'exécution de génération ayant échoué, ou à supprimer l'exécution de génération ayant échoué à l'aide de la commande ibmcloud ce buildrun delete. Par exemple :
```
ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
```

Pour les référentiels privés

Si l'échec s'est produit pour un référentiel privé, créez un secret SSH et utilisez le protocole SSH. Un secret SSH contient les données d'identification permettant d'accéder au référentiel privé qui contient le code source permettant de générer votre image de conteneur. Un secret SSH est également utilisé en tant que secret d'accès au référentiel Git. Le secret SSH contient une clé privée alors que la clé publique correspondante est stockée avec votre fournisseur de référentiel Git. Pour plus d'informations sur la création d'une paire de clés et le stockage de la partie publique dans GitHub ou GitLab, voir Accès aux référentiels de code privés. Il est important que votre fichier de clé privée ne soit pas chiffré avec une phrase passe pour pouvoir le transférer dans Code Engine. Le format du fichier de clé privée peut varier, ce qui complique l'évaluation de son éventuel chiffrement. Selon la version de l'outil ssh-keygen utilisée pour créer la paire de clés, le fichier peut avoir l'un des en-têtes suivants :

Si le fichier commence par -----BEGIN RSA PRIVATE KEY-----, il utilise le format PEM et a été créé avec une version antérieure de ssh-keygen. Si le fichier est chiffré avec une phrase passe, il contient généralement une ligne telle que la suivante : Proc-Type: 4,ENCRYPTED.
Si le fichier commence par -----BEGIN OPENSSH PRIVATE KEY-----, il a été créé avec une version plus récente de ssh-keygen. Pour vérifier qu'il soit bien chiffré avec un mot de passe composé, exécutez la commande ssh-keygen -p -f <ID_FILE>.
```
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):
```
Vous pouvez quitter la commande à l'aide des touches Ctrl+C. Si la commande exige l'ancienne phrase passe (premier exemple), cela signifie que le fichier d'origine a été chiffré, sinon elle demande directement la phrase passe du nouveau fichier (deuxième exemple).

Pour déchiffrer un fichier de clé privée chiffré, exécutez la commande suivante et laissez la nouvelle phrase passe vide.
```
$ 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.
```
Cette commande modifie le fichier de clé privée. Si vous devez conserver votre version chiffrée, faites-en d'abord une copie.

Pour créer un secret SSH et utiliser le protocole SSH,

Exécutez la commande ibmcloud ce secret create --format ssh. Un secret SSH est également utilisé en tant que secret d'accès au référentiel Git. L'attribut SSH_KEY_PATH doit pointer vers le fichier de clé privée correspondant à la clé publique de votre compte ou à la clé de déploiement du référentiel. Cette commande requiert un nom et un chemin de clé et autorise également d'autres arguments facultatifs, tels que le chemin d'accès au fichier hosts connu. Si vous spécifiez l'option --known-hosts-path, incluez l'hôte de votre référentiel Git, par exemple github.com ou gitlab.com, dans votre fichier d'hôtes connus. Pour plus d'informations, voir Accès aux référentiels de code privés.
```
ibmcloud ce secret create --format ssh --name <GIT_REPO_SECRET> --key-path <SSH_KEY_PATH> --known-hosts-path  <PATH_TO_KNOWN_HOSTS_FILE>
```
Utilisez la commande ibmcloud ce build update pour mettre à jour la configuration de génération afin d'utiliser l'URL SSH du référentiel Git et référencer le secret SSH, <GIT_REPO_SECRET>. Par exemple :
```
ibmcloud ce build update --name <BUILD_NAME> --source <GIT_REPO> --git-repo-secret <GIT_REPO_SECRET>
```
Dans l'exemple précédent, spécifiez l'URL SSH en utilisant le préfixe git@ pour votre source, ce qui donne --source git@github.com:IBM/CodeEngine.git.

Résolution d'un problème de révision incorrecte lors de la génération

Une configuration de génération spécifie le référentiel source en utilisant son URL et éventuellement une révision. La révision peut être soit le nom d'une branche ou d'une balise, soit un identificateur de validation. Par défaut, la branche main est générée. Consultez le message d'erreur pour obtenir des informations sur un élément qui a été spécifié mais qui n'existe pas.

Utilisez la commande ibmcloud ce build update pour mettre à jour la configuration de génération afin d'utiliser une révision correcte (ou une validation). Par exemple :
```
ibmcloud ce build update --name <BUILD_NAME> --commit <COMMIT>
```
Utilisez la commande ibmcloud ce buildrun submit pour soumettre une nouvelle exécution de génération. Pour la commande buildrun submit, vous devez spécifier l'option --build pour fournir le nom de votre configuration de génération. Vous pouvez éventuellement spécifier l'option --name pour fournir le nom de cette exécution de génération. Si vous spécifiez l'option --name, veillez à utiliser un autre nom d'exécution de génération que celui de l'exécution de génération ayant échoué, ou à supprimer l'exécution de génération ayant échoué à l'aide de la commande ibmcloud ce buildrun delete. Par exemple :
```
ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
```

Résolution d'une clé SSH arrivée à expiration lors de la génération

Lorsque vous utilisez une clé SSH pour vous connecter à votre référentiel source et que vous recevez une erreur indiquant que la clé SSH est arrivée à expiration, veillez à vérifier les paramètres de la clé SSH que vous utilisez comme secret d'accès au référentiel de code dans la génération ayant échoué.

Vous devez savoir comment la clé SSH a été créée, si elle a été créée pour un utilisateur spécifique ou si la clé SSH est une clé de déploiement Git dans le référentiel. Vous avez peut-être indiqué une expiration pour la clé. La définition d'une expiration pour une clé est une fonction de GitLab.

IBM Cloud® Continuous Delivery est basé sur GitLab. Pour plus d'informations, voir Continuous Delivery Git repos and issue tracking.

Pour résoudre cette erreur, procédez comme suit.

Si vous connaissez la clé SSH que vous utilisez dans Code Engine, mettez à jour la clé de déploiement ou d'utilisateur avec la même clé publique SSH dans GitLab. Avec la mise à jour, n'utilisez pas d'expiration ni de mise à jour vers une autre date d'expiration. Etant donné que vous utilisez la même clé SSH dans votre secret dans Code Engine, vous n'avez pas besoin de mettre à jour le secret d'accès au référentiel de code dans Code Engine.
Mettez à jour le secret d'accès au référentiel de code pour utiliser la nouvelle clé SSH.
1. Dans GitLab, utilisez la clé publique SSH pour créer une clé de déploiement ou une clé d'utilisateur.
2. Dans Code Engine, mettez à jour le secret d'accès au référentiel de code pour utiliser la nouvelle clé privée SSH.
  
  Par exemple, supposons que vous souhaitiez mettre à jour le secret d'accès au référentiel de code mysecret-ssh. Utilisez la commande ibmcloud ce secret update --format ssh pour mettre à jour un secret afin d'authentifier votre référentiel Git.
```
ibmcloud ce secret update --format ssh --name mysecret-ssh --key-path $HOME/.ssh/id_rsa --known-hosts-path $HOME/.ssh/known_hosts
```

Pour plus d'informations sur l'utilisation des clés SSH pour un référentiel de code, voir Accès aux référentiels de code privé.