5
votes

CircleCI pour iOS - Mise en cache des dépendances des cocoapodes

J'essaie d'exécuter ma suite de tests iOS dans CircleCI en utilisant fastlane scan . L'exécution des tests fonctionne très bien, mais le temps total est beaucoup augmenté en installant des dépendances à partir de cocoapods.

J'ai essayé de mettre en cache le répertoire Pods en faisant ce qui suit, cependant, la somme de contrôle change entre le restore_cache et l'étape save_cache :

- restore_cache:
    key: 1-pods-{{ checksum "Podfile.lock" }}
- run:
    name: Install Pods
    command: pod install
- save_cache:
    key: 1-pods-{{ checksum "Podfile.lock" }}
    paths:
      - ./Pods

Essentiellement, pod install fait changer la somme de contrôle même si aucun des pods n'a changé. En tant que tel, la clé sous laquelle il est enregistré dans le cache ne correspond jamais à ce qui tente d'être restauré à partir du cache.

Y a-t-il une meilleure façon de le faire?

ios continuous-integration cocoapods circleci

3 commentaires

peut-être que votre Podfile.lock engagé n'est pas à jour? pod install ne changera Podfile.lock que s'il y avait des changements sur votre podfile. J'ai la même manière exacte de restaurer et d'enregistrer et cela fonctionne bien

Avoir ce même problème. Avez-vous réussi à faire fonctionner les choses? J'ai essayé la solution de préfixe de clé, mais cela a entraîné une erreur de désynchronisation du bac à sable.

Je vois vraiment quel est le problème. J'ai utilisé cat pour imprimer mon Podfile.lock avant et après pod_install . La différence entre ce qui est archivé et ce qui est généré est que j'ai une source de dépôt privé. Dans la version générée, le fichier de verrouillage place un .git à la fin du nom du dépôt. Dans ma version enregistrée, ce n'est pas le cas. Bizarre cependant, les deux versions de cocoapodes sont les mêmes.

3 Réponses :

5
votes

Oui, il existe un moyen de faire fonctionner cela. restore_cache accepte les préfixes de clé ( https://circleci.com/ docs / 2.0 / configuration-reference / # restore_cache ). Donc, pour revenir à un cache antérieur, vous pouvez utiliser quelque chose comme ceci:

- restore_cache:
    keys:
      - 1-pods-{{ checksum "Podfile.lock" }}
      - 1-pods-

Il y a quelques directives plus spécifiques ici: https://circleci.com/docs/2.0/ios-migrating-from-1-2/#installing-cocoapods a>

0 commentaires

1
votes

Voici les étapes complètes.

  - restore_cache:
      key: 1-pods-{{ checksum "Podfile.lock" }}
  - run:
      name: Install CocoaPods
      command: |
        if [ ! -d "Pods" ]
        then
           curl https://cocoapods-specs.circleci.com/fetch-cocoapods-repo-from-s3.sh | bash -s cf
          bundle exec pod install
        fi
  - save_cache:
      key: 1-pods-{{ checksum "Podfile.lock" }}
      paths:
        - ./Pods

La première étape consiste à restaurer le cache.

Deuxième étape, si le cache n'est pas trouvé, mettez à jour le dépôt des pods à partir du miroir circleci et installez les pods. Cette étape prend environ 5 minutes, vous feriez donc mieux de la sauter si cela n'est pas nécessaire.

Troisième étape, enregistrez le cache si la clé n'est toujours pas occupée

source: https://medium.com/wandercodes/how-to-save-time -in-circleci-lors-de-l'utilisation-des-pods-4e00cd419ad8

0 commentaires

1
votes

OK, après avoir rencontré ce problème précis, je l'ai résolu moi-même. Je laisserai la solution ici au cas où cela finirait par être la même chose pour les autres.

Quoi?

Lorsque vous essayez de mettre en cache et de restaurer les dépendances de cocoapod sur circleci, la somme de contrôle utilisée pour ma clé de cache est différente à la restauration par rapport à la sauvegarde; résultant en ne jamais trouver une correspondance de clé de cache.

Pourquoi?

Lorsque circleci ajoutait mon dépôt en tant que source, il incluait l'extension .git à mon dépôt. Cependant, lorsque j'ai ajouté le dépôt à ma propre machine (c'est-à-dire, pod repo add , je n'ai pas inclus l'extension. Donc, sur ma machine locale lorsque j'exécuterais pod install , mon Podfile.lock listerait mon dépôt privé sans le .git , ce qui, bien sûr, prend en compte la génération de la somme de contrôle. Ensuite, sur circleci, il passerait par le même processus, mais générerait un Podfile.lock qui incluait l'extension .git , à son tour provoquant une somme de contrôle différente, et finalement une clé de cache différente.

Solution

Supprimez le dépôt privé de ma machine locale (c'est-à-dire pod repo remove ) et ajoutez-le à nouveau, en veillant à inclure l'extension .git comme partie de l'url (c'est-à-dire, pod repo add https://my-vcs.com/path-to/repo.git ).

Une note concernant l'utilisation de la méthode de secours mentionnée ci-dessus. Cela a en fait entraîné une erreur Sandbox désynchronisé , car les anciens caches contenaient des pods qui n'étaient plus alignés avec l'état actuel de l'application. J'éviterais donc probablement d'utiliser cette technique.

0 commentaires