Question

Nous prévoyons de migrer notre environnement de construction de l'application Web Java à Cloudbees, mais un aspect nous bloque actuellement.Nous développons une application multi-locataires.Il utilise le sous-domaine hôte pour identifier les locataires et nous utilisons des entrées de WildCard DNS pour le faire en production (par exemple: * .example.com).

Dans le développement, nous avons un code d'accès à quelques entrées dans notre fichier d'hôtes pour imiter cela.Ces entrées suffisent pour exécuter nos tests:

...
127.0.0.1   test1.app.dev
127.0.0.1   test2.app.dev
127.0.0.1   test3.app.dev
127.0.0.1   test4.app.dev

En gros, Jenkins doit définir le fichier hosts, puis lancer notre application à l'aide de notre conteneur Web localement.Ensuite, la suite de test est exécutée sur l'application Web en cours d'exécution.

J'ai essayé d'ajouter une étape de pré-processus dans la configuration du projet Jenkins pour éditer le fichier d'hôtes, mais comme prévu, le travail Jenkins n'a pas la permission de le faire.

Y a-t-il un moyen de modifier le fichier hosts avant que ma suite de test ne soit exécutée?Ou y a-t-il quelque chose d'autre que nous pourrions faire pour simuler des entrées DNS WildCard?

Était-ce utile?

La solution

Vous pouvez utiliser le service XIP.IO à partir de 37Signals:

http://37signals.com/svn/Posts / 3191-Annonce-Pow-040-With-Xipio-Support

Ainsi, vos noms d'hôte seraient

  • TEST1.127.0.0.1.XIP.IO
  • TEST2.127.0.0.1.XIP.IO
  • TEST3.127.0.0.1.XIP.IO
  • TEST4.127.0.0.1.XIP.IO

    J'essaie personnellement de les garder dans une zone configurée de manière centralisée, au cas où le service XIP.IO était déclassé, mais il est probablement assez bon marché de fonctionner et devrait donc être autour pendant au moins.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top