J'ai essayé d'ajouter l'intégration d'outils GitHub à ma chaîne d'outils, pourquoi l'intégration d'outils n'a-t-elle pas été ajoutée ?

Vous devez permettre l'accès à GitHub pour qu'IBM Cloud soit autorisé à accéder à votre compte GitHub.

L'intégration d'outils GitHub n'a pas été ajoutée à votre chaîne d'outils. Si vous utilisez Terraform ou l'API pour créer l'intégration d'outils GitHub, la tentative échoue avec le message d'erreur User is not authorized with https://api.github.com.

Si IBM Cloud n'est pas autorisé à accéder à votre compte GitHub, l'intégration d'outils n'est pas ajoutée à votre chaîne d'outils.

Si vous configurez l'intégration de l'outil GitHub en utilisant la console pendant que vous créez votre chaîne d'outils, suivez ces étapes pour vous autoriser avec GitHub::

1. A la section Intégrations configurables, cliquez sur GitHub.

2. Si vous créez la chaîne d'outils sur IBM Cloud Public et que IBM Cloud n'est pas autorisé à accéder à GitHub, sélectionnez la méthode d'authentification qui sera utilisée pour accéder à Github.

   • Si vous choisissez OAuth, cliquez sur Authorize pour accéder au site Web GitHub. Si vous n'avez pas de session GitHub active, vous êtes invité à vous connecter. Cliquez sur Autoriser IBM pour permettre à IBM Cloud d'accéder à votre compte GitHub.
   • Si vous choisissez Personal Access Token, spécifiez un jeton d'accès personnel valide pour GitHub.

Si vous utilisez la console et que vous disposez déjà d'une chaîne d'outils, mettez à jour la configuration de l'intégration d'outils GitHub:

1. Dans la console IBM Cloud, cliquez sur l' Menu > Automatisation de la plateforme > Chaînes d'outils. Sur la page Chaînes d'outils, cliquez sur la chaîne d'outils afin d'ouvrir sa page Vue d'ensemble. Vous pouvez également, sur la page Vue d'ensemble de l'application, sur la carte Livraison continue, cliquer sur Voir la chaîne d'outils > Vue d'ensemble.

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 et mettre à jour les paramètres de configuration pour autoriser IBM Cloud à accéder à GitHub.

   • Si vous choisissez OAuth, cliquez sur Authorize pour accéder au site Web GitHub. Si vous n'avez pas de session GitHub active, vous êtes invité à vous connecter. Cliquez sur Autoriser IBM pour permettre à IBM Cloud d'accéder à votre compte GitHub.
   • Si vous choisissez Personal Access Token, fournissez un jeton d'accès personnel valide pour GitHub.

4. Lorsque vous avez terminé la mise à jour des paramètres, cliquez sur Sauvegarder l'intégration.

Si vous utilisez Terraform ou l'API avec la méthode d'authentification OAuth, passez à l'utilisation d'un jeton d'accès personnel (PAT) pour fournir un accès granulaire à un utilisateur ou à un référentiel spécifique. L'autorisation avec un PAT est recommandée lorsque vous utilisez Terraform ou l'API. Sinon, vous pouvez utiliser la console pour autoriser IBM Cloud à accéder à votre compte GitHub:

1. Dans la console IBM Cloud, cliquez sur l' Menu > Automatisation de la plateforme > Chaînes d'outils. Sur la page Chaînes d'outils, localisez la chaîne d'outils à laquelle vous souhaitez ajouter l'intégration de l'outil GitHub. Cliquez sur la chaîne d'outils pour ouvrir sa page de présentation.
2. Sur la page de présentation de la chaîne d'outils, cliquez sur Ajouter.
3. Sur la page Ajouter une intégration d'outils, cliquez sur la carte d'outil GitHub.
4. Sur la page Configure GitHub, cliquez sur Authorize pour accéder au site Web GitHub. Si vous n'avez pas de session GitHub active, vous êtes invité à vous connecter. Cliquez sur Autoriser IBM pour permettre à IBM Cloud d'accéder à votre compte GitHub. Vous êtes redirigé vers la page Configurer GitHub.
5. Fermez la page sans effectuer d'autres actions dans la console, puis essayez de créer à nouveau l'intégration d'outils GitHub à Terraform ou à l'API.

Pourquoi ne puis-je pas utiliser l'intégration d'outils de Git Repos and Issue Tracking de la chaîne d'outils de ma région dans une chaîne d'outils appartenant à une autre région ?

Vous ne pouvez pas utiliser une instance de Git Repos and Issue Tracking dans plusieurs régions.

Lorsque j'essaie d'ajouter l'intégration d'outils de Git Repos and Issue Tracking à ma chaîne d'outils, je reçois le message d'erreur suivant :

Repository URL is not valid. The repository must be on {local GitLab URL}.

où {local GitLab URL} est l'URL de l'intégration d'outils de Git Repos and Issue Tracking de la région dans laquelle réside la chaîne d'outils.

Etant donné que Git Repos and Issue Tracking est étroitement intégré au service Continuous Delivery dans la région dans laquelle ils sont exécutés, vous ne pouvez pas utiliser une instance Git Repos and Issue Tracking dans plusieurs régions.

Au lieu de créer une intégration d'outils dans Git Repos and Issue Tracking, créez une intégration GitLab générique et utilisez cette intégration pour pointer vers le référentiel Git Repos and Issue Tracking dans une région différente.

1. Dans la console IBM Cloud, cliquez sur l' Menu > Automatisation de la plateforme > Chaînes d'outils. Sur la page Chaînes d'outils, cliquez sur la chaîne d'outils à laquelle vous souhaitez ajouter cette intégration. Vous pouvez également, depuis la page de présentation de l'application, sur la carte Distribution continue, cliquer sur Afficher la chaîne d'outils, puis sur Présentation.

2. Cliquez sur Ajouter un outil.

3. Dans la section Intégrations d'outils, cliquez sur GitLab.

4. Cliquez sur le serveur GitLab que vous souhaitez utiliser. Si le serveur GitLab où réside le référentiel auquel vous souhaitez accéder n'apparaît pas dans cette liste, ajoutez un serveur personnalisé :

   a. Cliquez sur Serveur personnalisé.

   b. Entrez un nom pour le serveur. Ce nom de serveur apparaîtra dans la liste des serveurs GitLab disponibles.

   c. Entrez l'adresse URL racine du serveur GitLab personnalisé.

   d. Entrez un jeton d'accès personnel de votre serveur GitLab personnalisé. Si vous n'avez pas de jeton d'accès personnel, créez-en un.

5. Si vous disposez d'un référentiel GitLab et désirez l'utiliser, cliquez sur Existant pour le type de référentiel et saisissez l'URL.

6. Si vous souhaitez utiliser un nouveau référentiel GitLab, indiquez un nom pour le référentiel, entrez l'URL du référentiel que vous clonez ou déviez, puis sélectionnez le type de référentiel :

   a. Pour créer un référentiel vide, cliquez sur Nouveau.

   b. Pour créer une copie d'un référentiel GitLab, cliquez sur Cloner.

   c. Pour dévier un référentiel GitLab afin de pouvoir participer aux modifications via des demandes d'extraction, cliquez sur Dévier.

7. Si vous voulez créer un référentiel public sur le serveur, désélectionnez la case Rendre ce référentiel privé.

8. Si vous voulez utiliser GitLab Issues pour le suivi des problèmes, cochez la case Activer GitLab Issues.

9. Si vous voulez suivre le déploiement des changements du code en créant des étiquettes et des commentaires sur les validations, ainsi que des libellés et des commentaires sur les problèmes référencés par les validations, cochez la case Suivi du déploiement des changements du code. Pour plus d'informations, voir Suivre où votre code est déployé avec les chaînes d'outils.

10. Cliquez sur Créer une intégration.

Pour en savoir plus sur la configuration d'une intégration d'outils GitLab, voir Configuration de GitLab.

Pourquoi ne puis-je pas cloner mon référentiel Git Repos and Issue Tracking sur https ?

Vous devez utiliser un jeton d'accès personnel ou une clé SSH pour effectuer des opérations Git.

Vous essayez d'envoyer ou de cloner un référentiel à partir de la ligne de commande en utilisant https et vous ne pouvez pas vous authentifier même si le mot de passe que vous entrez est correct.

Git Repos and Issue Tracking utilise un mécanisme de connexion unique qui ne prend pas en charge l'authentification Git qui utilise un nom d'utilisateur et un mot de passe sur la ligne de commande.

Pour effectuer des opérations Git comme des opérations de clonage ou d'envoi, vous devez utiliser un jeton d'accès personnel ou une clé SSH. Pour plus d'informations sur la création d'un jeton d'accès personnel ou une clé SSH, voir le tutoriel d'initiation.

Pourquoi me demande-t-on de m'authentifier lorsque j'essaie de cloner mon référentiel Git Repos and Issue Tracking avec SSH ?

Il est possible qu'il y ait des problèmes au niveau de l'emplacement ou des autorisations de votre clé privée SSH, ou que la ligne de commande Git n'utilise pas votre clé privée SSH pour s'authentifier dans Git Repos and Issue Tracking.

J'ai ajouté ma clé publique SSH via l'interface utilisateur Git Repos and Issue Tracking. Lorsque j'essaie de cloner un référentiel avec SSH, un mot de passe ou un code de sécurité m'est demandé ou un message d'erreur s'affiche indiquant que l'authentification a échoué.

Les problèmes SSH suivants peuvent vous inviter à vous authentifier ou faire apparaître un message d'erreur :

• La ligne de commande Git peut ne pas utiliser votre clé privée SSH pour s'authentifier dans Git Repos and Issue Tracking.

• Votre clé privée SSH n'est peut-être pas dans l'emplacement par défaut ~/.ssh/id_rsa.

• Votre clé privée SSH peut ne pas avoir les autorisations correctes (600).

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

• Si vous utilisez l'emplacement par défaut de la clé SSH privée, vérifiez les autorisations pour le dossier ~/.ssh/ et le fichier de clé privée ~/.ssh/id_rsa. Si les autorisations sont trop vastes, SSH n'utilise pas de clé privée par défaut. Assurez-vous que les autorisations pour le dossier ~/.ssh/ sont définies à 700 et que les autorisations pour le dossier ~/.ssh/id_rsa sont définies à 600.

• Si votre clé privée n'est pas dans l'emplacement par défaut, utilisez la commande suivante pour la spécifier dans une variable d'environnement :

  GIT_SSH_COMMAND='ssh -i/path/to/private_key_file' git clone git@host:owner/repo.git

• Pour résoudre ce problème en utilisant les informations de connexion, ajoutez l'indicateur -vv ou -vvv à la variable d'environnement GIT_SSH_COMMAND :

  GIT_SSH_COMMAND='ssh -vvv git clone git@host:owner/repo.git

  GIT_SSH_COMMAND='ssh -vvv -i/path/to/private_key_file' git clone git@host:owner/repo.git

J'ai tenté d'extraire des modifications de mon référentiel Git Repos and Issue Tracking, pourquoi est-ce que je reçois une erreur 504 Gateway Time-out ?

Votre référentiel est supérieur à 1 Go. Le système de gestion du contrôle de source Git n'est pas conçu pour stocker des fichiers binaires volumineux.

Lorsque j'essaie d'effectuer une opération sur un référentiel Git Repos and Issue Tracking (par exemple, une extraction ou un clonage), je reçois un message d'erreur :

git fetch error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out fatal: The remote end hung up unexpectedly

Vous disposez d'un référentiel volumineux supérieur à 1 Go. Le référentiel peut également contenir des fichiers binaires qui nécessitent plus d'espace que les fichiers texte stockés dans un format compressé.

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

• Réduisez la taille de votre référentiel Git Repos and Issue Tracking. Pour plus d'informations sur la réduction de la taille de votre dépôt, voir Réduire la taille du dépôt avec Git.

• Utilisez SSH pour ignorer le délai d'attente de clone par défaut de 180 secondes.

• Si vous tentez de cloner un référentiel, réalisez un clone peu profond (git clone --depth) afin de réduire la quantité de données transférées en tronquant l'historique de validation. Pour plus d'informations sur la réalisation d'un clone superficiel, voir la documentationGit Reference.

J'ai essayé d'ajouter un utilisateur à mon projet GitLab par email, mais il n'a pas reçu l'invitation. Comment puis-je l'ajouter à mon projet ?

L'invitation a pu être bloquée par la messagerie de l'utilisateur.

J'ai invité un utilisateur à mon projet GitLab en utilisant son adresse e-mail qui est listée dans Git Repos and Issue Tracking, mais il n'a pas reçu l'e-mail.

L'e-mail a peut-être été bloqué par le filtre antispam de la boîte de réception de l'utilisateur.

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

• Consultez de dossier spam de votre messagerie pour déterminer si le courrier d'invitation a été marqué en tant que spam. Les e-mails sont envoyés à partir d'une adresse noreply@. Mettez à jour vos filtres antispam pour autoriser les e-mails en provenance de cette adresse.

• Vérifiez si les filtres anti-spam de l'entreprise qui sont hors du contrôle de l'utilisateur bloquent l'e-mail. Demandez à l'utilisateur de se connecter à l'interface utilisateur de Git Repos and Issue Tracking et de vous envoyer son ID utilisateur. Vous pouvez ajouter l'utilisateur au projet GitLab en utilisant son ID utilisateur.

Lorsque j'utilise Terraform pour mettre à jour la configuration d'une intégration d'outils Git existante, pourquoi la configuration échoue-t-elle?

La ressource d'intégration d'outils Git spécifie un type clone, fork ou new et un référentiel cible existant.

Lorsque vous utilisez Terraform pour mettre à jour une intégration d'outil Git, la configuration échoue avec le message d'erreur The nonempty repository _REPO-URL_ already exists. Either delete the repository or change the Repository Type to 'Existing', où REPO-URL est l'URL du référentiel cible.

Cette erreur est souvent causée par les actions suivantes:

• Votre ressource Terraform d'intégration d'outils Git spécifie un type clone, fork ou new. Vous avez remplacé le repo_url dans le bloc initialization de la ressource par l'URL d'un référentiel existant.
• Votre ressource Terraform d'intégration d'outils Git spécifie un type clone, fork ou new. Vous n'avez pas modifié le repo_url, mais vous avez modifié un ou plusieurs autres arguments dans le bloc initialization de la ressource. Dans cette situation, le référentiel existe car il a été créé lorsque la ressource d'intégration d'outils Git a été précédemment appliquée par Terraform.

Les types clone, fork et new indiquent à l'intégration d'outils Git de créer le référentiel cible (repo_url) sur le principe que ce référentiel n'existe pas. Si l'intégration d'outils trouve le référentiel cible, elle échoue de par sa conception.

Remplacez type par clone, fork ou new par clone_if_not_exists, fork_if_not_exists ou new_if_not_exists. Ces types indiquent à l'intégration d'outils Git de créer le référentiel cible s'il n'existe pas ou d'utiliser le référentiel cible tel quel s'il existe.

Bien que vous puissiez utiliser d'autres méthodes pour résoudre cette erreur, ces méthodes ne sont pas recommandées car vous risquez de perdre des informations. Ces méthodes peuvent également nécessiter des modifications de votre Terraform qui ne sont pas de bonnes pratiques.

• Remplacez repo_url par un référentiel créé lorsque vous appliquez à nouveau votre Terraform. La modification d'une ressource Terraform après la création initiale pour éviter les erreurs lors des mises à jour suivantes est un anti-pattern. Cette méthode laisse également les référentiels précédemment créés intacts, mais n'est plus liée à la chaîne d'outils.
• Remplacez type par existing, puis appliquez à nouveau votre Terraform. La modification d'une ressource Terraform après la création initiale pour éviter les erreurs lors des mises à jour suivantes est un anti-pattern.
• Supprimez manuellement le référentiel cible, puis appliquez à nouveau votre Terraform. Les modifications manuelles entre les opérations Terraform automatisées par ailleurs ne sont pas recommandées. Si vous supprimez le référentiel, la suppression ne peut pas être annulée et peut entraîner une perte de données permanente.