configuration jenkins
Nacku
Membre
Bonjour,
Le server jenkins était dejà configuré et marche pour les anciens projets
J'ai du installé le plugin pour gérer les cocoaPods dans Jenkins
Les anciens projets étaient compilé avec Xcode 4.6
Mon nouveau projet doit être compilé avec Xcode 5
$ /usr/bin/xcodebuild -version
FATAL: Cannot run program "/usr/bin/xcodebuild" (in directory "/Users/jenkins/build/workspace/Projet/XXX/projetIOS7"): error=2, No such file or directory
java.io.IOException: Cannot run program "/usr/bin/xcodebuild" (in directory "/Users/jenkins/build/workspace/Projet/XXX/projetIOS7")
:
xcodebuild est bien sur le serveur mais c'est la version 4.6
jenkins$ xcodebuild -version
Xcode 4.6.3
Build version 4H1503
je continue à rechercher sur stackoverflow si vous voyez ce qui va pas toute sugestion serait bien venue
merci
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
S'il pointe toujours sur la 4.6 pour la ligne de commande, c'est un peu normal
J'ai lu ça :
http://tulusha.blogspot.fr/2012/04/jenkins-setup-for-building-xcode.html
du coup j'ai installé ce plugin :
si je comprends bien le message xcodebuild ne trouve pas de project à ce chemin là
1) Il y a plusieurs écoles concernant l'intégration continue de projets utilisant CocoaPods (il y a toute une discussion sur le blog de CP à ce sujet d'ailleurs) :
- Certains ne commitent pas les Pods sur leur repository, et du coup Jenkins est obligé de faire un "pod update" pour les récupérer. Je trouve pas que ce soit une bonne pratique car si des librairies se mettent à jour entre ton commit et le rebuild par Jenkins, tu n'auras plus le même contexte de compilation. Alors qu'on ne veut pas forcément toujours mettre à jour tous nos pods en continu, en général on prévoit une phase dédiée pour mettre à jour nos librairies, vu que cela peut avoir des implications
- D'autres, comme moi, commitent le dossier Pods, et du coup Jenkins n'a pas à faire de "pod update", il a déjà tous les pods quand il récupère le projet depuis le repo SVN ou GIT. Cela à l'avantage de ne pas obliger les développeurs bossant sur le projet à installer CocoaPods (mais seulement à l'architecte projet ou au lead developer qui s'occupe de la maintenance/mise à jour des pods). Il n'y a pas à installer CocoaPods sur Jenkins non plus. Il n'y a pas de risque d'auto-mise-à -jour-sans-prévenir des pods qui pourraient avoir des impacts négatifs (surtout si certains pods font des régressions non prévues)...
Perso je préfère donc commiter les pods, et du coup il n'y a plus de soucis concernant Jenkins non plus2) J'ai du mal à comprendre son exemple avec utilisation de rake et compilation du projet... Evidemment qu'il faut compiler le workspace. Il faut toujours demander de compiler le workspace quand on a un workspace (qu'on utilise CocoaPods ou non d'ailleurs). Donc j'ai du mal à comprendre sa remarque
3) C'est un peu pareil pour le cas du Scheme qu'il faut partager. C'est vrai qu'il faut le savoir qu'il faut cocher cette case, mais en même temps c'est juste pour que le scheme soit commité et donc que tout le monde (Jenkins comme les autres développeurs) se le partagent. Ca n'a encore une fois rien à voir avec CocoaPods.
4) En plus il fait des trucs bizarres, comme supprimer le dossier Pods et ensuite faire un "pod install" (au lieu d'un "pod update"), alors que les pods ont déjà été installés dans le projet principal (avec les configs créées et tout) donc c'est moyen comme idée...
Bref, tous les éléments qu'il évoque ne sont pas propres à CocoaPods, mais juste au fait que tu as un workspace et non juste un projet (en même temps qui a encore juste des projets sans workspace maintenant...). Et en plus s'il commitait son dossier "Pods" il n'aurait pas à installer CocoaPods sur la machine Jenkins, ni à faire de "pod update" (ou encore moins de "pod install"), et n'aurait pas de soucis avec CocoaPods qui serait un xcodeproj comme un autre dans un workspace.
Au final moi sur mon Jenkins la commande a toujours été un truc comme "xcodebuild -workspace <path> -scheme <scheme> -configuration Release" et je n'ai jamais eu à installer de plugin Jenkins spécialement pour CocoaPods ou pour les workspaces. J'ai juste eu à penser à cliquer sur "Shared" pour partager le scheme du projet de mon appli, et à commiter Pods. C'est tout
(Bon en vrai je préfère utiliser xctool que xcodebuild, mais c'est un autre débat)
merci Ali ! toujours avec tes réponses ! C'est toujours un plaisir
bon j'ai avancé ! j'avais un problème avec mon git ! probleme de merge dans ma branch master et ma branch develop. La maintenant j'ai un problème au linkage avec les pods
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch armv7s -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk -L/Users/jenkins/build/workspace/XXX/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch armv7s -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk -L/Users/jenkins/build/workspace/XXX/build/Release-iphoneos -F/Users/jenkins/build/workspace/XXX-v2/build/Release-iphoneos -filelist /Users/jenkins/build/workspace/XXX/build/XXX.build/Release-iphoneos/XXXX.build/Objects-normal/armv7s/XXX-Trombi.LinkFileList -dead_strip -ObjC -framework ImageIO -framework QuartzCore -fobjc-arc -fobjc-link-runtime -miphoneos-version-min=6.1 -framework Social -framework CoreText -framework CoreGraphics -framework CoreLocation -framework MessageUI -framework MapKit -framework ImageIO -framework QuartzCore -framework SystemConfiguration -framework UIKit -framework Foundation -lPods -Xlinker -dependency_info -Xlinker /Users/jenkins/build/workspace/XXX-v2/build/XXX.build/Release-iphoneos/XXX-Trombi.build/Release-iphoneos/XXX.build/Objects-normal/armv7s/XXX/build/Release-iphoneos -F/Users/jenkins/build/workspace/XXX-v2/build/Release-iphoneos -filelist /Users/jenkins/build/workspace/XXX-v2/build/XXX.build/Release-iphoneos/XXX.build/Objects-normal/armv7s/XXX.LinkFileList -dead_strip -ObjC -framework ImageIO -framework QuartzCore -fobjc-arc -fobjc-link-runtime -miphoneos-version-min=6.1 -framework Social -framework CoreText -framework CoreGraphics -framework CoreLocation -framework MessageUI -framework MapKit -framework ImageIO -framework QuartzCore -framework SystemConfiguration -framework UIKit -framework Foundation -lPods -Xlinker -dependency_info -Xlinker /Users/jenkins/build/workspace/XXX-v2/build/XXX.build/Release-iphoneos/XXX.build/Objects-normal/armv7s/XXX_dependency_info.dat -o /Users/jenkins/build/workspace/XXX-v2/build/XXX.build/Release-iphoneos/XXX.build/Objects-normal/armv7s/XXX
ld: library not found for -lPods
clang: error: linker command failed with exit code 1 (use -v to see invocation)
** BUILD FAILED **
The following build commands failed:
Ld build/XXX.build/Release-iphoneos/XXX.build/Objects-normal/armv7/XXX/normal armv7
Ld build/XXX.build/Release-iphoneos/XXX.build/Objects-normal/armv7s/XXX normal armv7s
(2 failures)
Build step 'Xcode' marked build as failure
- Pods.xcodeproj génére la lib "libPods.a", contenant tous les pods regroupés sous forme d'une grosse librairie statique
- TonAppli.xcodeproj contient juste le code de ton application (sans les pods donc)
- Ton appli qui doit être linkée avec la lib Pods (d'où le flag "-lPods" de la ligne de commande lors de la phase de link) pour assembler les 2 éléments ensemble
- Or seul le Workspace connait les 2 projets ensemble (c'est son rôle, un workspace est juste un conteneur de projets xcodeproj qui vont ensemble) et donc le lien (et surtout la dépendance) entre eux
Donc forcément si tu ne compiles que ton application mais pas le projet Pods, lorsqu'il va tenter d'assembler les 2 comme tu n'as compilé que TonAppli.xcodeproj il n'aura pas connaissance de Pods.xcodeproj et donc n'aura pas compilé et ne saura pas où trouver la lib Pods.
Ce n'est pas un problème propre à Jenkins ou à CocoaPods.
- Tu auras le même problème en local si tu ouvres avec Xcode le fichier TonAppli.xcodeproj tout seul et tente de le compiler dans son coin, il ne trouvera pas la lib pour -lPods.
- Alors que pourtant, quand tu travailles sur ton projet en local sur ta machine, c'est bien le workspace (le fichier xcworkspace) que tu ouvres avec Xcode (et non pas juste le xcodeproj de ton appli tout seul). Donc y'a pas de raison, c'est aussi celui là qu'il faut que tu demandes à Jenkins d'utiliser.
Y'a pas de raison que ce soit différent quand c'est Jenkins qui doit compiler ou quand c'est toi qui compile ton projet manuellement sur ton disque
ben en local j'arrive à compiler mon projet !
disons en local, xcode comprend qu'il faut compiler le workspace ^^
c'est au niveau de jenkins qui faut que je lui dise de compiler le workspace au lieu de compiler mon project seul ?
c'est cette ligne dans la config de jenkins qu'il faut configurer ?
Xcode Workspace File :
du coup j'ai renseigné le nom du workspace
J'obtiens ce message :
bon la je crois que personne pourra vraiment m'aider ! faut que je test et test pour trouver la bonne config
Si tu ouvres le xcodeproj avec Xcode, là il va faire la même erreur que Jenkins
Bah oui. Quand tu es sur ton Mac toi tu double-cliques sur le fichier xcworkspace dans le Finder pour ouvrir le workspace (car si tu double-cliquais sur le fichier TonAppli.xcodeproj et ouvrait le projet seul, ça compilerait pas). Donc quand tu es sur Jenkins faut bien lui dire d'ouvrir/utiliser lui aussi le fichier xcworkspace et pas le fichier xcodeproj ! Sinon comment veux-tu qu'il devine ?
Je sais pas, moi j'utilise pas le Plugin Jenkins spécial pour Xcode. Donc je n'ai pas cette case.
Moi je tape directement la ligne de commande "xcodebuild -workspace MonWorkspace.xcworkspace -scheme MonSchemePartagé -configuration Release" dans la case où Jenkins me permet d'indiquer la ligne commande à exécuter pour lancer le Job.
Là du coup cette erreur n'a rien à voir avec la compilation en elle-même ou Xcode ou autre. L'erreur arrive avant même qu'il essaye d'ouvrir le workspace ou le projet et d'essayer de le compiler, l'erreur arrive quand il essaye de récupérer le code de ton dépôt SVN ou GIT.
En gros là si on traduit l'erreur, Jenkins te dit juste qu'il n'arrive pas à trouver la branche de ton repository SVN (ou GIT) qu'il doit builder. Il ne sait pas quelle révision SVN (ou quel commit GIT) builder. Et il te dit donc de vérifier, dans la configuration du Job Jenkins, ce que tu as configuré concernant l'URL du repository et concernant les branches.
Bonjour maintenant il me crie qu'il ne trouve pas le scheme :
pourtant j'ai bien renseigné le scheme qui se trouve en haut à gauche à coté du carré.
pourtant j'ai bien un scheme dans le dossier :
Bonjour,
As-tu coché la case shared des schemes dans Xcode?
en local je l'ai bien mis en shared mais toujours pareil
comment voir si c'est bien en shared sur le git. J'avais l'habitude d'utiliser svn
Tu vas le voir le fichier dans ton repo git .../xcshareddata/xcschemes/???.xcscheme
exemple :
https://github.com/AliSoftware/OHHTTPStubs/tree/master/OHHTTPStubs/OHHTTPStubs.xcodeproj/xcshareddata/xcschemes
J'ai bien le fichier scheme
Au niveau de jenkins ca pose pas de probleme qu'on soit sur la branch develop ?
sinon on se posait la question entre collegue est ce que xcode compile pour les 2 branch si y a devlop et master dans les branch dans jenkins
Une fois que tu auras coché la case "Shared" en face du scheme dans Xcode, ton fichier xcscheme passera dans le dossier "xcshareddata" et non plus "xcuserdata". Et du coup évidemment il faudra penser à le commiter sur le GIT pour que les autres postes (y compris Jenkins) le récupèrent quand ils font un "git pull".
En général si tu as fait un fichier .gitignore digne de ce nom, on ignore le dossier "xcuserdata" car il ne faut pas le commiter (ce sont les réglages propres à chaque user, comme le nom du dossier le laisse penser), mais on n'ignore surtout pas le dossier "xcshareddata" qui justement contient ce qu'il faut partager sur le repo.
Tu peux dire à Jenkins la ou les branches que tu veux qu'il surveille.
Dès qu'il va voir (soit parce que tu lui as demandé de vérifier toutes les X minutes ou toutes X heures, soit parce que tu as branché un "webhook" sur ton GIT pour déclencher un build automatiquement à chaque "git pull") qu'il y a une modification sur l'une des branches que tu lui as demandé de surveiller, il va récupérer le code de ladite branche et le compiler.
Donc si tu as mis "develop" et "master" dans le champ "branches" de Jenkins, il va surveiller les 2 branches, et dès qu'il y a des nouveaux commits poussés sur une de ces branches il va compiler la branche en question. S'il y a des modifications sur une seule des branche il va compiler la branche concernée. (S'il y a des modifications sur les 2 branches il va détecter la modification sur la première puis sur la 2ème, donc faire 2 compilations à la suite donc sur le principe ça change rien)
ok mais est ce qu'il y a deux repertoires pour les build produit au le build construit ecrase le précédent qu'il ait été construit depuis develop ou master
Comme ça t'es sûr qu'avant de commencer à compiler il fait le ménage et que tu risques pas d'avoir des trucs des anciennes compilations qui trainent.
OK merci pour tes précisions
J'ai l'impression que j'ai résolu mon probleme de scheme ! la compilation se déroule (cf console de log)
puis elle s'arrete
ca peut venir d'ou ? pour que le process de compilation s'interrompte
le message apparait après être entrain dans la mise en place de la signature
Bonjour, je reviens sur mon problème d'intégration continu
Malgré le BUILD Failed j'ai un MyApp.app de généré qui se trouve dans :
/Users/jenkins/Library/Developer/Xcode/DerivedData/XXXX-agzzvblythxqffbkvfiyvclbbojz/Build/Products/Release-iphoneos
L'application généré prend comme certificat pour une application métier.
est ce que ce qu'il est possible d'installer ce .app sur un device ? faudrait t'il que j'arrive à la rappatrier sur mon poste en local
j'essaie de comprendre la doc d'Apple https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/ConfiguringYourApp/ConfiguringYourApp.html#//apple_ref/doc/uid/TP40012582-CH28-SW1
Mais je ne suis un peu débossoulé ! à quel niveau intervient l'Ipa