J'ai créé une chaîne d'outils et le service Delivery Pipeline ne s'initialise pas. Pourquoi l'initialisation du pipeline n'aboutit-elle pas ?

Vous devez peut-être configurer et sauvegarder à nouveau l'intégration d'outils GitHub.

L'intégration d'outils GitHub de votre chaîne d'outils est peut-être mal configurée, ce qui empêche l'initialisation du pipeline de se terminer.

Un problème lié aux événements s'est produit et a entraîné l'échec de l'intégration d'outils GitHub.

Configurez et sauvegardez à nouveau l'intégration d'outils GitHub :

1. Dans la console IBM Cloud, cliquez sur l'icône Menu > Automatisation de la plateforme > Chaînes d'outils. Sur la page Chaînes d'outils, cliquez sur la chaîne d'outils que vous avez créée pour ouvrir la page Vue d'ensemble. Sinon, sur la page Détails de l'application de votre application, cliquez sur le nom de la chaîne d'outils.
2. Sur la page Présentation de la chaîne d'outils, sur la carte Référentiels, recherchez l'intégration de l'outil GitHub.
3. Cliquez sur le menu pour accéder aux options de configuration, mettez à jour les paramètres et cliquez sur Sauvegarder l'intégration.
4. Sur la carte Pipelines de livraison, cliquez sur l'intégration de l'outil Delivery Pipeline pour afficher la configuration du pipeline.

Pourquoi le pipeline n'est-il pas créé correctement lorsque je crée une chaîne d'outils à partir du modèle que j'écris ?

Il se peut que votre pipeline manque de ressources telles que des travaux et des étapes en raison d'une erreur dans la définition de votre fichier pipeline.yaml.

Lorsque j'essaie de créer une chaîne d'outils à partir d'un modèle que j'écris, je reçois le message d'erreur suivant sur la page Pipeline :

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.

Ce problème est généralement causé par une erreur dans la définition de votre fichier pipeline.yaml.

Vous pouvez utiliser les méthodes suivantes pour corriger cette erreur :

• Utilisez l'interface utilisateur du pipeline pour créer un exemple de pipeline qui réplique le pipeline que vous essayez de construire avec votre modèle. Ajoutez /yaml à l'URL du pipeline pour générer un fichier pipeline.yaml similaire que vous pouvez utiliser pour rechercher les différences évidentes. Par exemple, https://cloud.ibm.com/devops/pipelines/<your pipeline id>/yaml?env_id=<your region>.

• Utilisez le mécanisme de création de chaîne d'outils sans interface graphique. Sur la page Créer une chaîne d'outils, ouvrez le débogueur et évaluez l'expression window.Testflags = {nocreate: 1}. Lorsque vous cliquez sur Créer une chaîne d'outils dans ce mode, la chaîne d'outils n'est pas créée. Au lieu de cela, les informations qui sont transmises à l'API sont renvoyées à la console où vous pouvez les examiner.

Pourquoi est-ce que j'obtiens une erreur d'accès au référentiel Git (repo) lorsque j'essaie d'exécuter un pipeline ?

Le pipeline utilise un jeton d'accès pour cloner le référentiel Git. Si ce jeton n'est pas valide, le propriétaire de l'intégration Git ne peut pas accéder au référentiel Git.

Les intégrations Git prises en charge incluent les intégrations GitHub, GitLab, Bitbucket ou Git Repos and Issue Tracking.

Lorsque j'essaie d'exécuter un pipeline, je reçois le message d'erreur suivant :

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.

Le jeton d'accès utilisé par le pipeline pour cloner le référentiel Git n'est plus valide. Ce problème peut se produire lorsque le jeton a été invalidé. Le jeton d'accès peut aussi ne plus être valide lorsque le propriétaire de l'intégration Git n'a plus accès au référentiel suite à une modification des droits d'accès.

Configurez et sauvegardez à nouveau l'intégration Git :

1. Dans la console IBM Cloud, cliquez sur l'icône Menu > Automatisation de la plateforme > Chaînes d'outils. Sur la page Chaînes d'outils, cliquez sur la chaîne d'outils qui contient l'intégration Git que vous souhaitez mettre à jour pour ouvrir la page Présentation qui lui est associée. Sinon, sur la page Détails de l'application de votre application, cliquez sur le nom de la chaîne d'outils.
2. Sur la page Présentation de la chaîne d'outils, sur la carte Référentiels, recherchez l'intégration de l'outil Git.
3. Cliquez sur le menu pour accéder aux options de configuration, sélectionnez le compte Git autorisé pour le propriétaire de l'intégration Git et cliquez sur Sauvegarder l'intégration.
4. Exécutez de nouveau votre pipeline.

J'ai tenté de déployer une application sur Kubernetes à l'aide de Delivery Pipeline, pourquoi est-ce que j'obtiens une erreur au sujet d'un objet non valide ?

L'image de base de pipeline 1.0 inclut kubectl v1.14.2. Il est possible que vous obteniez une erreur si le cluster Kubernetes auquel vous vous connectez utilise une version plus récente de Kubernetes.

Lorsque je tente de déployer dans Kubernetes à l'aide de Delivery Pipeline, je reçois le message d'erreur suivant :

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

Ce problème se produit généralement lorsque la version de la commande kubectl dans votre image de base de pipeline n'est pas compatible avec la version de Kubernetes utilisée dans le cluster.

Vous pouvez utiliser l'une des méthodes suivantes pour résoudre ce problème :

• Utilisez une version plus récente de l'image de base de pipeline, qui inclut la version en cours de kubectl lorsqu'elle est créée. Pour obtenir des informations sur la manière dont vous pouvez spécifier la dernière version d'image, voir Spécification de la version d'image.

• Vérifiez que votre travail de pipeline utilise la version correcte de kubectl. Par exemple, ajoutez les lignes suivantes au début de votre travail de pipeline pour exécuter kubectl v1.14.2 :

  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

Si vous exécutez kubectl v1.14.2 à partir d'une image de base de pipeline de version 1.0, l'option sudo n'est pas disponible. Remplacez la ligne sudo par la commande suivante pour ajouter kubectl à votre chemin d'accès :

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

Pour plus d'informations sur l'accès à la version exacte de kubectl dont vous avez besoin, voir Installer et configurer kubectl.

J'ai essayé d'exécuter un pipeline et une erreur 403 est renvoyée par IBM Cloud Container Registry. Pourquoi ?

Le pipeline IBM Cloud® Container Registry insère et extrait des images dans et depuis IBM Cloud Container Registry. Le plan de service IBM Cloud Container Registry détermine la quantité de stockage et le trafic de téléchargement que vous pouvez utiliser pour vos images privées.

Lorsque j'essaie d'exécuter un pipeline, je reçois le message d'erreur suivant :

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

Vous avez dépassé vos limites de quota de trafic d'extraction. L'image Docker ne peut donc pas être extraite.

Vérifiez l'utilisation et les limites de quota pour le stockage et l'extraction d'images. Libérez de l'espace de stockage utilisé et changez de plans de service ou de limites de quota pour rester dans les limites données.

J'ai essayé de compiler mon application dans un seul travail de pipeline, pourquoi l'opération a-t-elle échoué ?

4 Go de mémoire (pas de magasin de fichiers) sont requis pour générer votre application dans un seul travail de pipeline.

Lorsque j'essaie de compiler mon application dans un seul travail de pipeline, l'exécution échoue avec une erreur inattendue.

Votre application requiert 4 Go de mémoire pour être compilée dans un seul travail de pipeline.

Pour générer votre application dans un seul travail de pipeline :

1. Créez un agent privé IBM Cloud® Continuous Delivery Pipeline.
2. Configurez votre travail de génération de manière à utiliser l'agent privé.

Pourquoi Delivery Pipeline ne peut-il pas communiquer via un pare-feu ?

La configuration de votre pare-feu empêche Delivery Pipeline de communiquer avec des environnements qui se trouvent derrière un pare-feu.

Lorsque j'essaie d'utiliser Delivery Pipeline, il ne peut pas communiquer via mon pare-feu.

Votre pare-feu doit être configuré pour permettre à Delivery Pipeline de communiquer avec des environnements derrière un pare-feu.

Vous pouvez mettre à jour vos configurations de pare-feu pour autoriser Delivery Pipeline à accéder aux ressources qui se trouvent derrière le pare-feu. Utilisez la CIS liste blanche et les plages de sous-réseaux correspondant à votre région spécifique.

Pourquoi ai-je reçu une notification indiquant que les références de référentiel sont fixées dans mes déclencheurs ou définitions de pipeline ?

Vous avez modifié, ajouté ou supprimé des intégrations de référentiel de votre chaîne d'outils, ce qui a entraîné des références aux intégrations stockées dans les déclencheurs de pipeline ou les définitions à devenir non valides.

Lorsque je change, ajoute ou supprime des intégrations de référentiel de ma chaîne d'outils, des icônes d'avertissement et des erreurs de validation s'affichent dans ma configuration de pipeline.

Dans certains scénarios, lorsque vous modifiez, ajoutez ou supprimez des intégrations de référentiel de votre chaîne d'outils, les références à ces intégrations stockées dans les déclencheurs de pipeline ou les définitions risquent de devenir invalides.

Si une intégration de référentiel correspondante se trouve dans la chaîne d'outils, le pipeline tente de mettre à jour automatiquement ces références pour corriger les références d'intégration non valides. Une notification s'affiche dans l'interface utilisateur avec l'un des messages suivants :

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

Si vous voyez l'une de ces notifications, mais qu'aucun avertissement ou erreur ne s'affiche dans la configuration, aucune autre action n'est requise. Si des avertissements ou des erreurs apparaissent toujours, il peut être nécessaire de mettre à jour ou de créer à nouveau le déclencheur ou la définition.

Pourquoi mon pipeline se bloque-t-il lorsqu'il essaie de se connecter aux points d'extrémité privés IBM Cloud Object Storage

Lorsque vous exécutez un pipeline, les requêtes adressées au IBM Cloud Object Storage qui utilisent un point de terminaison privé expirent sans réponse. Ce délai peut entraîner l'échec du pipeline.

IBM Cloud Object Storage Les points de terminaison privés ne sont pas accessibles depuis tous les types IBM Cloud de clusters. Les points de IBM Cloud Object Storage terminaison privés ne sont pas accessibles depuis les travailleurs privés qui s'exécutent sur des clusters au sein d'un IBM Cloud® Virtual Private Cloud (VPC).

Remplacez tous s3.private.*IBM Cloud Object Storage les points de terminaison par s3.direct.* des points de terminaison. s3.direct.* Les points de terminaison sont des points de terminaison directs qui communiquent avec IBM Cloud Object Storage à partir de n'importe quel IBM Cloud type de cluster.

Pourquoi mon pipeline échoue-t-il avec une erreur liée aux propriétés sécurisées?

PipelineRuns échoue avec une erreur lorsque l'une des propriétés sécurisées du pipeline ne se résout pas au début de l'exécution du pipeline.

Les pipelines qui ne peuvent pas récupérer une valeur secrète à partir d'un magasin de secrets ou de Secrets Manager, Key Protect, ou HashiCorp Vault, échouent avec un message d'erreur qui indique les propriétés qui ne peuvent pas être résolues. Des échecs de résolution peuvent se produire même si les propriétés ne sont pas utilisées directement dans l'exécution déclenchée. Par exemple, des échecs de résolution peuvent se produire si le chemin d'accès au secret dans le magasin n'est plus valide, si le magasin de secrets est inaccessible ou pour des problèmes d'autorisation.

Si vos pipelines contiennent des propriétés sécurisées qui ne sont pas résolues actuellement, mettez à jour ces propriétés pour qu'elles fassent référence à des secrets valides et récupérables situés dans Secrets Manager, Key Protect, ou HashiCorp Vault.

Assurez-vous que votre pipeline spécifie uniquement les propriétés sécurisées requises pour que l'exécution d'un PipelineRun déclenché aboutisse en tant que propriétés de déclencheur de pipeline, et non en tant que propriétés d'environnement de niveau pipeline. Utilisez les propriétés d'environnement au niveau du pipeline uniquement lorsque cela est nécessaire.

Pourquoi mon pipeline signale-t-il une erreur lors de l'extraction de la définition de pipeline?

Une erreur apparaît sur la Delivery Pipeline page concernant la récupération de la définition du pipeline. Sinon, l'erreur apparaît lorsque vous essayez de déclencher un PipelineRun.

Il existe un certain nombre de raisons pour lesquelles un échec peut se produire lors de l'extraction de la définition d'un pipeline. Par exemple, si la définition est définie dans un grand référentiel, la demande de récupération de la définition peut être retardée en raison d'un délai dans le clonage du grand référentiel avant la construction de la définition. Un autre exemple est lorsqu'une entrée de définition est ciblée sur une branche ou un chemin qui n'existe plus dans le référentiel.

Essayez de résoudre le problème à l'aide de l'une des options suivantes:

• Rechargez la page pour lancer une nouvelle demande d'extraction de la définition. Si cela échoue à plusieurs reprises, continuez avec les options suivantes.
• Vérifiez que toutes les branches et tous les chemins référencés dans vos entrées de définition correspondent aux ressources qui existent dans le référentiel.
• Réduisez la taille du référentiel contenant votre définition Tekton. Supprimez les fichiers inutiles du référentiel et mettez à jour votre .gitignore pour exclure le téléchargement de fichiers inutiles.
• Incluez uniquement les fichiers minimum nécessaires de votre définition de pipeline: ne ciblez pas l'intégralité de votre référentiel. Déplacez tous les fichiers de définition Tekton dans un sous-dossier de votre référentiel, puis modifiez l'entrée de définition dans vos paramètres Delivery Pipeline pour cibler le chemin d'accès au sous-dossier. Cette option réduit le temps nécessaire au clonage des fichiers de définition à partir de votre référentiel.
• Pour les définitions Tekton volumineuses, envisagez de diviser la définition en plusieurs dossiers ou en plusieurs dépôts. Ensuite, mettez à jour les entrées de définition dans votre Delivery Pipeline pour cibler les dossiers ou les dépôts nécessaires.

La limite de capacité de calcul du pipeline est de 1 Mo. Si vous rencontrez des erreurs lors de la sauvegarde ou de l'exécution de votre pipeline, vous devrez peut-être réduire la taille de votre définition de pipeline ou la diviser en plusieurs pipelines.

Pourquoi mon pipeline ne parvient pas à se connecter à un cluster Red Hat OpenShift on IBM Cloud ?

Les pipelines qui tentent une oc login ne peuvent pas se connecter au cluster cible qui exécute Red Hat OpenShift on IBM Cloud la version 4.13 et les versions ultérieures.

Le problème est dû à une modification introduite dans la version 4.13 de Red Hat OpenShift on IBM Cloud.

Pour contourner le problème, procédez comme suit:

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

Pourquoi mon pipeline échoue-t-il lors de l'exécution d'une commande de clonage Git?

Les pipelines Tekton qui utilisent la tâche de commande 'git-clone-repo peuvent échouer avec l'erreur suivante affichée :

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

Le problème est dû à un changement de performance dans l'infrastructure des travailleurs des pipelines gérés par l'État.

Pour résoudre cet incident, procédez comme suit :

• Localisez les définitions tekton sous Settings pour votre pipeline et trouvez l'entrée pour 'git sous Path. Cliquez sur le lien du dépôt pour l'ouvrir. Naviguez jusqu'au " git/task-clone-repo.yaml et, dans ce fichier, trouvez l'étape " clone-repo. Voir l'exemple de catalogue Tekton pour le code le plus récent à titre de référence.
• Ajouter rm -rf "lost+found" à la définition avant l'appel git clone. Cela permet de s'assurer que le répertoire de clonage est vide.
• Exécutez à nouveau le pipeline.

Pourquoi mon pipeline ne démarre-t-il pas sur les travailleurs gérés lorsqu'il est exécuté à partir d'un compte d'essai ?

Les pipelines classiques exécutés à partir d'un compte d'essai ne démarrent pas en raison de l'erreur suivante :

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.

Ce comportement est provoqué par une révision des droits des comptes d'essai.

Essayez les options suivantes pour résoudre ce problème :

• Exécutez vos pipelines en utilisant un employé privé fonctionnant sur votre propre cluster.
• Mettez à niveau votre compte d'essai vers un compte Paiement à la carte avec un plan Lite.

Pourquoi mon pipeline ne se déclenche-t-il pas pour les événements de demande d'extraction provenant de dépôts forkés ?

Par défaut, les pipelines ne répondent pas aux événements de pull request des dépôts forkés

Ce comportement a été conçu pour éviter l'exécution involontaire de pipelines.

Pour permettre aux pipelines de s'exécuter sur des événements provenant de référentiels forkés, procédez comme suit :

• Tekton Pipelines : Dans la fenêtre du déclencheur Git, activez la bascule Include pull request events from forks
• Pipelines classiques : Dans l'onglet Input de la configuration de l'étape, activez la bascule 'Include pull request events from forks

Pourquoi le site ExceededNodeResources apparaît-il parfois dans les événements Pod de mon pipeline?

Parfois, lorsqu'une tâche prend plus de temps que prévu à démarrer, des messages avec une reason valeur de ExceededNodeResources peuvent être affichés dans la vue des événements du pod de la tâche sur la page pipelineRun de détails.

Cela se produit généralement lorsqu'une tâche tente d'utiliser un volume déjà monté sur un nœud surchargé. Cela peut également se produire lorsque la grappe est surchargée et qu'il faut du temps pour mettre en place un nouveau nœud lors d'un événement de mise à l'échelle automatique de la grappe.

Ces messages sont probablement des messages opérationnels normaux provenant de votre Kubernetes cluster. Aucune intervention de l'utilisateur n'est généralement requise pour ces types de messages. Elles se produisent soit lorsqu'un événement de mise à l'échelle automatique se produit, libérant des ressources à utiliser, soit lorsque des ressources deviennent disponibles par la suite. Le pipeline se met donc en place une fois que le pod est programmé. Essentiellement, le pipeline attend que les ressources nécessaires deviennent disponibles par le biais de l'autoscaling ou d'autres moyens, ce qui permet au pod d'être déployé et au pipeline de continuer.

Pourquoi est-ce que je rencontre des erreurs réseau lorsque j'utilise un Docker ou Podman un sidecar?

Lorsque j'exécute un pipeline Tekton avec un Docker sidecar Podman ou, je constate un ou plusieurs des symptômes suivants :

• Délais d'expiration de connexion intermittents
• Les requêtes/réponses volumineuses échouent tandis que les petites réussissent
• Les services fonctionnent correctement au niveau local, mais échouent dans le cluster
• TLS échec de la poignée de main

Il existe une incompatibilité MTU entre le démon Docker et le réseau hôte. Le démon DockerPodman interne crée son propre réseau pont avec un MTU par défaut de 1500, mais l'interface réseau du pod peut ne prendre en charge que 1450 octets en raison de l'encapsulation de la superposition. C'est cette incompatibilité qui provoque les pannes du réseau.

Mettez à jour la définition du pipeline pour définir explicitement la mtu valeur pour docker comme suit :

• Docker: com.docker.network.driver.mtu: 1400
• Podman: podman network create --opt mtu=1400 ou dans certains cas, définir --network=host