CI CI - Comment exécuter des tests fonctionnels?

Depuis la version 1.3.0 Il semble que vous puissiez exécuter docker-composer dans une tâche: HTTPS: //github.com/concours/concours/issues/324

Ceci semble fonctionner: P>

jobs:
  - name: docker-compose
    public: true
    serial: true
    plan:
      - do:
        - task: docker-compose
          timeout: 20m
          privileged: true
          config:
            platform: linux
            image_resource:
              type: docker-image
              source: {repository: "mumoshu/dcind", tag: "latest"}
            run:
              path: sh
              args:
                - -exc
                - |
                  source /docker-lib.sh
                  start_docker
                  docker ps
                  docker-compose version

Cela ne sonne pas cela compliqué pour moi. J'ai écrit un message sur la façon d'obtenir quelque chose de similaire et d'exécuter Ici . J'utilise certains conteneurs différents pour la pile et le coureur de test et enflammez tout d'un docker officiel: Dild image avec Docker-Compose installé sur elle ...

Au-delà du concours habituel CI de choses de récupération de ressources, etc. Effectuer une analyse de test comporterait: p>

1. Démarrage du Web, de repos et d'autres services avec Docker-Compose Up. Li>
2. Démarrage du service Testrunner et tirer les tests-suites sur le page Web qui communique avec la couche de repos, qui est à son tour dépend des autres services pour les réponses. LI>
3. effectuer Docker-Composez-vous lorsque le coureur de test complète et décider du code de retour de la tâche (0 = échec, 1 = succès) en fonction de le code de retour de la suite de test. LI> ol>

   Pour une configuration proprement et une déchirure de la pile et du coureur de test, vous pouvez faire quelque chose comme ci-dessous (peut-être que vous pourriez utiliser dépend Si votre service n'est pas démarré lorsque le test commence, pour moi, cela fonctionne sans) p>

   # Setup the SUT stack:
   docker-compose up -d
   ‌‌
   # Run the test-runner container outside of the SUT to be able to teardown the SUT when testing is completed:
   docker-compose run --rm test-runner --entrypoint '/entrypoint.sh /protractor/project/conf-dev.js --baseUrl=http://web:9000/dist/ --suite=my_suite'
   ‌‌
   # Store the return-code from the tests and teardown:
   rc=$?
   docker-compose down
   echo "exit code = $rc "
   kill %1
   exit $rc
   

C'est le commentaire de l'auteur du concours:

Il n'y a pas de binaire ni de socket de docker sur l'hôte - ils utilisent simplement un backend de jardin (probablement gardien). Le hall passe à une couche d'abstraction au-dessus de Docker, offrant ainsi une sorte de magie qu'il n'a pas vraiment de sens.

La seule chose qui manque post-1.3 est que Docker vous oblige à configurer des cgroups vous-même. J'ai oublié à quel point c'est ennuyeux. Je souhaite qu'ils aient fait ce que gardien le fait et la configurez automatiquement, mais que peut-on faire.

Donc, le jeu complet d'instructions est:

Utilisez ou une image de construction d'une image avec Docker dedans, par ex. Docker: Dind. Exécutez ce qui suit au début de votre tâche: https://github.com/concourse/docker-image-resource/blob/master/assets/common.sh#l1-l40 Spin up Docker avec Docker Daemon &.

Ensuite, vous pouvez exécuter Docker-Compose et amis comme normal.

L'inconvénient est que vous allez chercher les images à chaque fois. # 230 va aborder cela.

à long terme, # 324 (commentaire) est la direction que je veux aller.

voir ici https://github.com/concourse/concours/issues/324

Comme dans la réponse acceptée, les données d'archives relâchées sont supprimées (due à la limite de relâchement)

L'image Docker spécialisée pour l'Usecase: https://github.com/meamidos/dcind