web-dev-qa-db-fra.com

Comment se construit l'accélérateur travis-ci.org?

Mon entreprise utilise travis-ci.org (la version gratuite pour les logiciels open source) pour créer automatiquement des demandes d'extraction vers notre référentiel sur github. Nous avons environ 20 personnes qui soumettent des demandes de tirage au même référentiel tout au long de la journée et chacune d'elles est intégrée dans une matrice qui comprend deux tâches de génération par génération. Nous remarquons souvent qu'il faut un certain nombre de minutes - et parfois des heures - pour qu'une build démarre une fois qu'elle a été envoyée à travis. (Symptôme: la version apparaît sur travis mais le minuteur ne démarre pas et il n'y a pas de sortie console pendant un certain temps.)

Je suppose que cela se produit parce que travis-ci.org est soit sauvegardé, soit accéléré. Tout d'abord

  • Travis étrangle-t-il intentionnellement/build-limit-rate?

Si oui, comment les builds sont-ils limités?

  • Par connexion? (c'est-à-dire par utilisateur/organisation github, etc.)
  • Par repo?

Les builds sont-ils limités

  • Par "Build"?
  • Par "Build Job"?

Sachant cela, nous pourrons optimiser notre temps de construction dans les limites des contraintes fixées par travis-ci.org (ce qui, nous l'espérons, correspond à jouer à Nice en tant qu'utilisateur gratuit).

travis-ci
36
Danny Roberts

Si vous consultez la page d'état travis-ci ( http://www.traviscistatus.com/ ), vous remarquerez que les "Builds Linux actifs pour les projets Open Source" sont périodiquement maximisés. Sur la base du fonctionnement du système de construction privé travis (une seule file d'attente pour tous les "travaux de construction" avec pas plus de x en cours d'exécution), je soupçonne qu'ils ont une seule file d'attente pour tous les travaux de génération open source.

Vous pouvez diviser votre build en plusieurs tâches, chacune se terminant plus rapidement. Lorsque Travis est sous utilisation légère, ils s'exécuteraient en parallèle et votre version reviendra plus tôt, mais lorsque Travis exécute de nombreuses autres versions, la vôtre ne peut s'exécuter que de manière séquentielle.

En regardant le .travis.yml dans le référentiel que vous avez publié, vous pouvez remarquer de bonnes augmentations de performances en ajoutant la mise en cache apt et pip ( http://docs.travis-ci.com/user/caching/ ). Vous devriez également envisager de passer à la nouvelle infrastructure basée sur des conteneurs de Travis ( http://docs.travis-ci.com/user/workers/container-based-infrastructure/ ). Cela ne fonctionnera cependant que si vous pouvez remplacer le Sudo apt-get commandes dans votre build.

26
MattyB

Travis-CI fournit actuellement cinq versions simultanées pour les projets open source, et cela est pris en compte dans tous les référentiels par connexion ou organisation GitHub, comme l'a découvert Apache Software Foundation . Travis comptabilise chaque "tâche de build", dans tous les projets et demandes de tirage, vers cette limite de builds simultanés.

17
shoyer

Sur Travis CI, toutes les versions sont mises en file d'attente, indépendamment de votre connexion ou de votre référentiel.

De plus, si vous jetez un œil à l'historique du statut de Travis CI (ici http://www.traviscistatus.com/history ), vous verrez qu'ils ont remarqué et étudié le problème que vous avez décrit le 7 avril. et le 8 avril. Ils ont également fait une mise à jour de leur environnement de build le 9 avril ( http://docs.travis-ci.com/user/build-environment-updates/2015-04-09/ ). Pendant la mise à jour, la file d'attente à traiter augmente et doit être traitée ultérieurement. Cette combinaison de choses est probablement à l'origine des longs retards que vous avez subis.

J'espère que cela t'aidera.

4
Guillaume Pascal

J'utilise Travis pour un usage personnel et j'ai très peu de builds par jour. J'ai souvent remarqué un délai de quelques minutes avant le début de la construction, ce qui est probablement normal. Après quelques recherches, je n'ai pas pu trouver de très bons chiffres sur les limites de Travis, mais ils en ont certainement ( source ). Il s'agit d'un problème GitHub demandant s'ils peuvent limiter les builds par projet afin qu'ils n'atteignent pas leur limite utilisateur/entreprise aussi rapidement. Cela signifie qu'une certaine limite est appliquée. La version gratuite est décrite comme "Fair Use", donc je ne sais pas exactement ce que cela signifie. Si vos builds sont lents, j'examinerais accélérant la build afin que vous en tiriez le meilleur parti avant d'atteindre votre limite.

Désolé, je ne peux pas offrir les chiffres réels, mais vous devriez faire de votre mieux pour optimiser les versions telles quelles. Je suppose qu'ils peuvent ne pas avoir de limites strictes car ils sont probablement encore en croissance et changent ce que leurs systèmes peuvent gérer.

Quelques chiffres que j'ai trouvés:

Je vais continuer à chercher les nombres limites et mettre à jour ma réponse si/quand je les amende.

1
Christian Juth