Les échanges avec GitHub se font en passant par SSH afin de chiffrer les communication est assurer un minimum de sécurité.

Dans la mise en place du compte GitHub explique comment créer une paire de clefs RSA, comme mettre la clef publique sur dans les paramètres du compte GitHub.

Tout cela est très bien, mais me pose (et peux vous poser) un problème. J’ai déjà des paires de clefs SSH dans mon $HOME/.ssh. Comment faire pour avoir une clef spécifique et utiliser celle là au moment des push/pull ?

Génération de la paire de clefs

La première entorse aux instructions de GitHub se fait dès la création de la paire de clef. Au lieu de laisser faire ssh-keygen, je donne le nom du fichier que je veux pour ma clef privée, ici github.rsa

 ssh-keygen -t rsa -C "github@example.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): /home/user/.ssh/github.rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/github.rsa.
Your public key has been saved in /home/user/.ssh/github.rsa.pub.
The key fingerprint is:
8f:12:12:1e:76:3f:b9:4a:2c:60:fd:62:f3:da:36:b4 github@example.com

Il faut ensuite déposer la clef publique (~/.ssh/github.ras.pub) sur le serveur en suivant les instructions de GitHub… Encore une fois pas jusqu’au bout.

Pour testes la connectivité nous devons modifier la commande proposée :

# ssh -T git@github.com -i $HOME/.ssh/github.rsa
Enter passphrase for key '/home/jfoucry/.ssh/github.rsa':
Hi jfoucry! You've successfully authenticated, but GitHub does not provide shell access.

Macédoine d’instructions

GitHub propose de configurer de façon globale (mot clef global dans les commandes git). Personnellement, ça me dérange, j’utilise git avec d’autres dépôts et j’aimerais laisser la configuration global tel quelle est.

Avant la série d’instruction qui consiste à mettre le nom du développeur et le token GitHub dans la configuration GLOBAL de git, nous allons créer le répertoire local qui contiens nos sources.

# mkdir ~/Documents/Sources/projets/MonProjet
# cd ~/Documents/Sources/projets/MonProjet
# git init 

Notre dépôt local de référence est créé, c’est maintenant que nous allons reprendre les instructions de GitHub, avec une petite différence, nous allons retirer le mot clef global :

# git config github.user userName
# git config github.token MonToken
# git config user.name "Prenom Nom"
# git config user.email "github@example.com"

SSh, le retour de la vegeance du petit fils

Si nous continuons les instructions de GitHub, nous allons avoir un problème. La commande git ne va pas trouver la bonne clef privée pour dialoguer avec le serveur GitHub. Nous devons ruser en utilisant une des fonctionnalités de OpenSSH, j’ai nommé, le fichier $HOME/.ssh/config.

Dans ce fichier nous allons indiquer comment joindre le serveur GitHub. Mais voyez plutôt :

host github
	Hostname github.com
	user git
	IdentityFile /home/jfoucry/.ssh/github.rsa

La première ligne est un petit nom pour le serveur, le seconde indique l’adresse ou le nom du serveur, user DOIT être git dans cette configuration, et IdentityFile est le chemin vers la clef privée.

Ré-essayons la commande que GitHub propose pour tester une fois le fichier sauvegardé. Cette fois, j’utilise le petit nom de ma configuration.

ssh -T github
Enter passphrase for key '/home/jfoucry/.ssh/github.rsa':
Enter passphrase for key '/home/jfoucry/.ssh/github.rsa':
Hi jfoucry! You've successfully authenticated, but GitHub does not provide shell access.

Finissons-en maintenant

En effet, nous pouvons maintenant reprendre la documentation de GitHub (avec encore quelques modification mineures).

# touch README
# git add README
# git commit -m "First commit"
# git remote add origin github:jfoucry/MonProjet.git
# git push -u origin master

J’utilise le petit de ma configuration SSH.

Pour cloner, on utiliser à nouveau le petit nom :

# git clone github:jfoucry/MonProjet.git
Cloning into 'MonProjet'...
Enter passphrase for key '/home/jfoucry/.ssh/github.rsa':
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Receiving objects: 100% (3/3), 211 bytes, done.

Nous avons vu comment installer Java, Jenkins et faire un premier flux Jenkins pour compiler une application OSX.

Un flux pour iOS sur Simulateur

Cette fois-ci, nous allons voir comment faire une application iOS destinée au simulateur. En ligne de commande depuis une machine sous Linux l’intérêt est très limité. Mais ce deuxième flux va nous permettre d’avoir un squelette pour notre but ultime, la compilation d’une application iOS pour un périphérique et sa diffusion « Over The Air » (OTA).

Nous allons donc faire un nouveau job Jenkins. Appelons le iOS_Build.

Comme pour le précédent nous allons désigner un dépôt Git pour un projet iOS.

La commande de compilation est toujours « Execute Shell » avec la commande suivante :

xcodebuild -target MonProjet -configuration Debug -sdk iphonesimulator5.0

• target doit être une target connue dans votre projet. Si vous n’avez pas en tête la liste des target de votre projet, vous pouvez utiliser certains paramètres de xcodebuild

xcodebuild -list -project /Users/Shared/Jenkins/Home/jobs/iOS_Build/workspace/MonProjet.xcodeproj
Information about project "MonProjet":
    Targets:
        MonProjet
        MonProjetTests

    Build Configurations:
        Debug
        Release

    If no build configuration is specified and -scheme is not passed then "Release" is used.

    Schemes:
        MonProjet

• Configuration correspond à l’une des configurations de build de votre projet. Vous avez dû noter que la ligne de commande précédente vous donnait aussi les configurations de build
• sdk indique le SDK à utiliser ; ici il s’agit du SDK 5.0 pour le simulateur. Pour connaître la liste des SDK disponibles sur votre machine, utilisons encore une fois xcodebuild

xcodebuild -showsdks
Mac OS X SDKs:
        Mac OS X 10.6                   -sdk macosx10.6
        Mac OS X 10.7                   -sdk macosx10.7

iOS SDKs:
        iOS 5.0                         -sdk iphoneos5.0

iOS Simulator SDKs:
        Simulator - iOS 5.0             -sdk iphonesimulator5.0

Si vous avez de la chance, votre build va fonctionner rapidement. Si ce n’est pas le cas regardez les traces dans Jenkins pour savoir ce qui ne fonctionne pas.

Un flux pour iOS sur iDevice

Et pour une compilation iOS, comment faire ? Partons du même projet, en le dupliquant (New Job et choisissez Copy existing job et donnez le nom de votre flux précédent).

Ce qui va changer dans ce nouveau, c’est une fois de plus la ligne de commande qui exécute xcodebuild.

Le premier changement est le SDK. iphonesimulator5.0 devient iphoneos5.0. Si vous décidez de tenter une compilation immédiatement, celle-ci va échouer.

Code Sign error: There are no valid certificate/private key pairs in the default keychain

Il faut indiquer à xcodebuild le certificat de signature de code à utiliser.

Note : Vous aurez besoin de la clef privée, de votre certificat de développeur et du provising profile de votre projet. Le plus simple est de passer par l’application Keychain Access (Trousseau d’Accès) sur votre machine de développement).

Jouons avec la keychain et les certificats

.

Export avec l’interface graphique du Trousseau d’accès

Dans les certificats, sélectionnez celui qui correspond à celui généré par Apple pour votre compte développeur et exportez-le. La clef privée est comprise dans cet export. Choisissez une extension .p12 (format pkcs12).

Export à la ligne de commande

Note à l’attention des chevelus qui nous lisent : ici, commence la vieillesse et la calvitie. Samson, si tu tiens à ta crinière fuit loin des keychain..
Toutefois, il est intéressant de le faire à ligne de commande pour rester dans le cadre de ce tutoriel.

Donc, sur la machine de développement, nous allons extraire les informations qui nous intéressent.

% security export -k login.keychain -t identities -f pkcs12 -o $HOME/identities.p12 -P "passphrase"

La passphrase est celle de l’ouverture de votre keychain.

Transférez le fichier résultant sur votre machine de build. J’ai déposé le mien dans /Users/Shared.

Passons maintenant sur la machine de build. Pour apprendre des tas de choses (et parce que je n’ais pas d’écran branché sur cette machine) je vais manipuler la keychain à la ligne de commande.

Commençons pas obtenir la liste des keychain existantes :

% security list-keychains
    "/Users/jacques/Library/Keychains/login.keychain"
    "/Library/Keychains/System.keychain"

Nous pouvons également connaître le contenu des keychains avec security dump-keychain ce qui va nous permettre de savoir si nous avons les éléments nécessaires à la compilation des applications iPhone.
Nous avons besoin du certificat racine d’Apple, du certificat du développeur, de sa clef privée et de sa clef publique.

Recherchons le certificat racine d’Apple :

% security dump-keychain | grep -i "Apple Code Signing Certification Authority"
    "alis"<blob>="Apple Code Signing Certification Authority"
    "labl"<blob>="Apple Code Signing Certification Authority"
    "subj"<blob>=0x307F310B300906035504061302555331133011060355040A130A4150504C4520494E432E31263024060355040B131D4150504C452043455254494649434154494F4E20415554484F52495459313330310603550403132A4150504C4520434F4445205349474E494E472043455254494649434154494F4E20415554484F52495459  "0\1771\0130\011\006\003U\004\006\023\002US1\0230\021\006\003U\004\012\023\012APPLE INC.1&0$\006\003U\004\013\023\035APPLE CERTIFICATION AUTHORITY1301\006\003U\004\003\023*APPLE CODE SIGNING CERTIFICATION AUTHORITY"
    "issu"<blob>=0x307F310B300906035504061302555331133011060355040A130A4150504C4520494E432E31263024060355040B131D4150504C452043455254494649434154494F4E20415554484F52495459313330310603550403132A4150504C4520434F4445205349474E494E472043455254494649434154494F4E20415554484F52495459  "0\1771\0130\011\006\003U\004\006\023\002US1\0230\021\006\003U\004\012\023\012APPLE INC.1&0$\006\003U\004\013\023\035APPLE CERTIFICATION AUTHORITY1301\006\003U\004\003\023*APPLE CODE SIGNING CERTIFICATION AUTHORITY"

Il est présent, tout va bien.

Cherchons à présent les informations sur le développeur (iPhone Developper) :

%  security dump-keychain | grep -i "iPhone Developer"

Je n’ai aucune réponse sur ma machine, preuve que je n’ai pas ces informations dans une keychain. Il va donc falloir importer les éléments dans une keychain. Et tout d’abord créer une nouvelle keychain.

Attention, il est nécessaire de faire cette keychain pour l’utilisateur qui fait tourner Jenkins, il faut donc devenir Jenkins

% su - jenkins

Nous allons commencer par nous assurer que jenkins accède aux certificats racine d’Apple. C’est normalement le cas, ces certificats étant dans la keychain System.

% security dump-keychain | grep -i "Apple Code Signing Certification Authority"
    "alis"<blob>="Apple Code Signing Certification Authority"
    "labl"<blob>="Apple Code Signing Certification Authority"
    "subj"<blob>=0x307F310B300906035504061302555331133011060355040A130A4150504C4520494E432E31263024060355040B131D4150504C452043455254494649434154494F4E20415554484F52495459313330310603550403132A4150504C4520434F4445205349474E494E472043455254494649434154494F4E20415554484F52495459  "0\1771\0130\011\006\003U\004\006\023\002US1\0230\021\006\003U\004\012\023\012APPLE INC.1&0$\006\003U\004\013\023\035APPLE CERTIFICATION AUTHORITY1301\006\003U\004\003\023*APPLE CODE SIGNING CERTIFICATION AUTHORITY"
    "issu"<blob>=0x307F310B300906035504061302555331133011060355040A130A4150504C4520494E432E31263024060355040B131D4150504C452043455254494649434154494F4E20415554484F52495459313330310603550403132A4150504C4520434F4445205349474E494E472043455254494649434154494F4E20415554484F52495459  "0\1771\0130\011\006\003U\004\006\023\002US1\0230\021\006\003U\004\012\023\012APPLE INC.1&0$\006\003U\004\013\023\035APPLE CERTIFICATION AUTHORITY1301\006\003U\004\003\023*APPLE CODE SIGNING CERTIFICATION AUTHORITY"

Apparemment, tout va bien.

Créons notre keychain, que nous appellerons Jenkins.keychain pour des raisons de commodité, mais que vous pouvez nommer comme vous le désirez.

% security create-keychain jenkins.keychain
password for new keychain:
retype password for new keychain:

% security list-keychains
    "/Users/Shared/Jenkins/Home/Library/Keychains/jenkins.keychain"
    "/Library/Keychains/System.keychain"

Parfait, notre keychain est créée. Il faut maintenant importer les éléments issus de l’export de la machine de developpement.

% security list-keychains
    "/Users/Shared/Jenkins/Home/Library/Keychains/jenkins.keychain"
    "/Library/Keychains/System.keychain"
macmini:~ jenkins$ security import /Users/Shared/FoucryJacques.p12 -k jenkins.keychain -t cert -f pkcs12 -T /usr/bin/codesign -T /usr/bin/xcodebuild -P motDePasse
1 identity imported.

• le chemin vers le fichier .p12
• -t cert, nous importons un certificat
• -f pkcs12, il s’agit du format dans lequel se trouvent les données
• -T xxxx, les applications qui ont accès à l’identité, ici xcodebuild et codesign
• -P le mot de passe qui verrouille le fichier p12. Ce mot de passe a été renseigné au moment de l’export sur la machine de développement

Histoire d’être certains du succès de l’opération, vérifions que la keychian est bien renseignée :

% security dump-keychain | grep -i "iPhone Developer"
    "alis"<blob>="iPhone Developer: Jacques Foucry (K45L6X42KM)"
    "labl"<blob>="iPhone Developer: Jacques Foucry (K45L6X42KM)"
    "subj"<blob>=0x308193311A3018060A0992268993F22C6401010C0A3454354E4D52535036593136303406035504030C2D6950686F6E6520446576656C6F7065723A204A61637175657320466F7563727920284B34354C365834324B4D2931173015060355040B0C0E4A61637175657320466F7563727931173015060355040A0C0E4A61637175657320466F75637279310B3009060355040613024652  "0\201\2231\0320\030\006\012\011\222&\211\223\362,d\001\001\014\0124T5NMRSP6Y1604\006\003U\004\003\014-iPhone Developer: Jacques Foucry (K45L6X42KM)1\0270\025\006\003U\004\013\014\016Jacques Foucry1\0270\025\006\003U\004\012\014\016Jacques Foucry1\0130\011\006\003U\004\006\023\002FR"

Nous avons besoin de mettre le Provisioning Profiles dans un répertoire ~/Library/MobileDevice/Provisioning Profiles

Avant de reprendre la configuration de Jenkins, nous allons tenter de faire une compilation du produit en utilisant la même ligne de commande que celle que nous allons mettre dans le flux. Il faut bien sûr d’abord récupérer les sources avec une commande git clone.

Une fois les sources sur un coin de votre disque, rendez-vous dans le répertoire du projet et tentez la commande suivante :

% xcodebuild -sdk iphoneos5.0 -project PillStock.xcodeproj -target MonProjet -configuration "Release"
...
/tmp/MonProjet/build/Release-iphoneos/PillStock.app: User interaction is not allowed.
Command /usr/bin/codesign failed with exit code 1

** BUILD FAILED **

Oh Oh, ça ne fonctionne pas… Le point c’est important est un peut plus haut : User interaction is not allowed.

En fait, notre keychain est fermé, il est nécessaire de l’ouvrir pour permettre l´accès aux données qu’elle contient.

% security unlock-keychain jenkins.keychain
% xcodebuild -sdk iphoneos5.0 -project PillStock.xcodeproj -target MonProjet -configuration "Release"
...
** BUILD SUCCEEDED **

Pas mal non ?

La même dans Jenkins

Sur ce coup-là, nous allons allez très vite. Un nouveau job, le dépôt git, la ligne de commande dans Execute Shell, test et PAF le chien !

La compilation échoue et les traces nous indiquent que xcodebuild ne peux pas signer les sources. Sans doute parce qu’il ne trouve pas le certificat dans la keychain par défaut.

Je vais vous épargner du temps. La keychain par défaut, c’est System.keychain. Parfais, mettons le certificat et la clef privée dans la keychain System… Ne marchera pas non plus, j’ai essayé.

Il semble en fait que la jvm et donc jenkins ne dialogue pas au même process pour ouvrir les keychain et les activer. Il en résulte que les processus de compilation ne peuvent pas accéder aux keychains ouverte par d’autres processus.

Notre problème n’est pas forcément insoluble, mais risque de nous demander de déployer une énergie assez importante. Comment passer outre ?

J’ai tenté pour vous l’idée du script qui déverrouille la keychain et fait la compilation. Pas de résultat positif non plus.

Alors, que faire ?

Comme vous le savez sans doute si vous lisez le blog, j’écris mes livres en utilisant Docbook.

C’est à partir des sources Docbook et d’une xslt adéquate que je génère le PDF destiné à l’impression.

C’est à partir des mêmes sources et d’une autre XSLT que je génère un PDF personnalisé pour chacun des acheteurs.

Et c’est avec les mêmes sources et une troisième XSLT (plus une CSS et des scripts python) que je peux créer une version EPUB.

Ainsi donc, les acheteurs de « Mac OS X Server à votre service, troisième édition, Snow Lepoard » se verront livrer une version PDF et une version EPUB.

Nous nous retrouvons donc avec la liste des prix suivante :

Rendez-vous sur la page boutique.

Dans notre premier épisode nous avons vu comment installer Java, Jenkins, et compiler, sans trop de difficulté une application OSX. Dans le deuxième épisode, nous avons joué avec la keychain et nous nous sommes rendu compte que même avec un script nous avions des problèmes.

À qui la faute ?

Après avoir longtemps cherché, la faute en est à la keychain. Pour faire une compilation destinée à un iDevice, le code doit être signé avec le certificat développeur. Dans la keychain on trouve l’identité du développeur. Même, ne déveouillant la keychain contenant cette identité et en la rendant keychain par défaut, le flux Jenkins s’obstine à chercher les éléments dans la keychain System. La solution, bien que sale, semble de mettre les éléments dans cette Keychain. Mais non, là encore, l’identité n’est pas trouvée.

Alors, qu’est-ce qu’on fait ?

On pourrait laisser tomber… ou s’obstiner… ou partir sur une autre idée. J’ai choisi la troisième option et ait décidé de faire un script python qui va tout faire pour moi !

Pourquoi Python ?

Parce que… J’ai envie d’apprendre Python depuis longtemps et j’ai l’occasion de m’y mettre avec ce script. Python dispose d’une foultitude de modules dont certain qui peuvent nous simplifier la vie dans ce cas.

Quelle version ?

Bien que la version 3.x de Python soit disponible depuis un petit bout de temps maintenant, nous allons rester sur la dernière des versions 2.x, la 2.7.x. En effet, de nombreux modules n’ont pas encore été portés pour Python3.

Synopsis de notre script

Dans les grandes lignes notre script doit appeler xcodebuild pour compiler notre projet, appeler xcrun pour transformer le .app issue de la compilation en .ipa, créer un fichier manifest.plist utilisé pour la distribution OTA et envoyer le tout vers la machine de distribution.

Nous verrons bien vite qu’il va falloir ajouter des fonctionnalités pour permettre à ces quatre étapes d’opérer correctement.

Découper le script en fonction

Nous allons découper notre script en fonction. C’est plus facile à tester, plus facile à comprendre et moins long à écrire.

xcodebuild, la ligne de commande

Commençons par la ligne de commande qui permet la compilation de notre projet.

% xcodebuild -project MonPrpject.xcodeproj -target maTarget -sdk iphoneos5.0 --configuration Release

Si vous renseignez correctement les variables et que votre projet compile sur votre machine de développement, il est fort probable que cette compilation fonctionne.

Intégrons cela dans une fonction :

def compileApp(SDK, project, configuration, target):
	cmd_array=(["/usr/bin/xcodebuild","-sdk",SDK,"-project ",project,"-configuration",configuration, "-target", target])
	try:
		subprocess.check_call(cmd_array)
	except OSError as e:
		logger.debug("Error in %s. Exiting"% " ".join(cmd_array))
		writeToSTDERR("Error, please see the log file")
		sys.exit(1)

Cette fonction ne marche pas telle quelle. En effet, elle utilise subprocess.check_call qui fait partie du module subprocess, d’un logger pour mettre des traces dans un fichier externe. Nous allons aussi avoir besoin de récupérer, de la ligne de commande qui lance notre script, des paramètres.

Écriture du script

#!/usr/bin/python2.7
# -*-coding:utf-8 -*-

Tout d’abord le chemin vers l’interpréteur de notre script, ici python 2.7. Ajoutons une ligne qui indique le codage utilisé pour le script.

import logging
import os
import sys
import subprocess
import argparse

Import des modules dont nous aurons besoin. os et sys sont importants ils permettent de dialoguer avec l’OS. Les deux autres logging et subprocess sont ceux dont nous avons besoin dans nos fonctions. Enfin, argparse est celui qui va nous permettre de récupérer les arguments de la ligne de commande.

Au cours de notre développement, nous aurons besoin d’autres modules, il faudra ajouter ici la ligne d’importation nécessaire.

Récupération des paramètres

Pour récupérer les arguments passés en paramètres, nous avons besoin d’un objet de type ArgumentParser. Nous allons ensuite ajouter à cet objet les arguments que nous acceptons, avec un court message d’aide et le nom de la variable qui accueillera la valeur transmise.
Enfin, nous allons copier les valeurs dans des variables plus facilement manipulables. Nous allons également ajouter un paramètre pour régler le niveau de trace que nous voulons dans notre fichier de trace.

Les paramètres sont stockés dans un tableau (parser.parse-args). Nous copions ce tableau et de cette copie nous extrayons les valeurs.

# --- Parse arguments with argparse

parser = argparse.ArgumentParser(description=xcodebuild wrapper parameters') parser.add_argument('-P', '--projectPath', action="store", required=True, dest="project", help="Path to the project file")
parser.add_argument('-s', '--sdk', action="store", required=True, dest="sdk", help="SDK")
parser.add_argument('-c', '--configuration', action="store", required=True, dest="config", help="Configuration")
parser.add_argument('-t', '--target', action="store", required=True, dest="target", help="Path to projet's file")

parser.add_argument('--log', action="store", dest="logLevel", help="LogLevel, could be DEBUG | INFO | WARNING | ERROR | CRITICAL. Default value is INFO", default="INFO")

args = parser.parse-args()

project = args.project
SDK = args.sdk configuration = args.configuration target = args.target logLevel = args.logLevel

Avant de continuer, mettons en place le logger.

# --- Logger Initialization
 logger = logging.getLogger('xcodebuild-wrapper')
 logHandler = logging.FileHandler('/tmp/xcodebuild-wrapper.log')
 formatter = logging.Formatter('%(asctime)s %(levelname)s %(message)s')
 logHandler.setFormatter(formatter)
 logger.addHandler(logHandler)

# --- Define LogLevel

if logLevel=="DEBUG":
  logger.setLevel(logging.DEBUG)
 elif logLevel=="INFO":
  logger.setLevel(logging.INFO)
 elif logLevel=="WARNING":
  logger.setLevel(logging.WARNING)
 elif logLevel=="ERROR":
  logger.setLevel(logging.ERROR)
 elif logLevel=="CRITICAL":
  logger.setLevel(logging.CRITICAL)
 else:  logger.info('Unkown loglevel '+ debugLevel +', using INFO')

Voilà, nous avons tous les éléments nécessaires pour notre première fonction. Celle-ci doit être définie AVANT son appel.
Pour l’appeler, il suffit de mettre son nom avec entre parenthèses les paramètres qu’elle attend.

compileApp(SDK, project, configuration,target)

Transformer l’application .app en .ipa

La fonction compileAPP prend votre projet et tous les éléments dont il a besoin pour en faire un bundle .app. Or, sur un iDevice ce ne sont pas des app qui tournent, mais des .ipa (qui sont en fait des fichiers zippés). Il faut donc transformer notre .app en .ipa. cela se fait avec xcrun. xcrun ne fait rien en lui même. Il appelle un autre outil de développement PackageApplication.

Voici la fonction createIPA qui réalise cette transformation:

def createIPA(GSDK, workspace, configuration, target, DeveloperName, ProvisioningProfile,targetFolder,APPPath):
  cmd_array=(["/usr/bin/xcrun","-sdk",GSDK, "PackageApplication", "-v"," %s/%s.app"% (APPPath,target),"-o","%s/%s.ipa"%(targetFolder,target),"-sign",""%s""%(DeveloperName), "-embed",""%s""%(ProvisioningProfile)])

  try:
   subprocess.check_call(cmd_array)
  except OSError as e:
   logger.debug("Error in %s. Exiting"% " ".join(cmd_array))
   logger.info(" Error String == %s Error Num == %d"% (e.strerror, e.errno))
   writeToSTDERR("Error, please see the log file")
sys.exit(1)

Le principe est le même que précédemment, la ligne de commande est décomposée et mise dans un tableau. Tout de suite nous voyons que nous avons besoin d’autres paramètres. Il va donc falloir ajouter des lignes à la réception des paramètres.

Les paramètres qui manquent sont :

• GSDK
• workspace
• DeveloperName
• ProvisioningProfile
• APPPath
• targetFolder

Définition des paramètres

Certains de ces paramètres (GDSK, APPPath et workspace) sont issus de variables déjà connues. GSDk est SDK sans le numéro de releases (iphoneos5.0 devient iphoneos), workspace est le répertoire qui contient le projet, APPPath est le répertoire dans lequel on trouve le .app résultat de la compilation. Plaçons la définition de ces variables avant l’appel au compileAPP.

workspace = os.path.dirname(project)
GSDK = SDK[:-3]
APPPath="%s/build/%s-%s"%(workspace,configuration,GSDK)

targetFolder est le répertoire dans lequel nous allons placer le fichier .ipa (et d’autres choses). Ce répertoire doit être différent pour chaque compilation. Afin qu’il soit unique nous allons le nommer du nom de la target plus le timestamp courant. Une fois son nom défini, nous allons le créer à l’aide d’une fonction. La définition est à placer juste après celles de nos autres variables, la fonction doit être avant compileAPP et l’appel doit lui aussi se trouver avant l’appel à compileAPP.

La définition:

timestamp = int(time.time())
 targetFolder="/tmp/%s-%d"%(target,timestamp)
 logger.debug("targetFolder == %s"%(targetFolder))

La fonction :

def createTargetFolder(folder):
  try:
   subprocess.call(["/bin/mkdir", folder])
  except OSError as e:
   if os.path.exists(folder):
    logger.info("%s folder already exist, Exiting")
    logger.debug("ErrorString == %s ErrorNum == %d"% (e.strerror,e.errno))
    pass
   else:
    raise Exception("Error in creating %s folder"% (folder))
    writeToSTDERR("Error, please see the log file")
  sys.exit(1)

import time

Ajout dans la gestion des paramètres

Pour ce qui est de la récupération des paramètres, il faut ajouter le ProvisioningProfile et le DeveloperName. D’abord sous forme de add_argument :

parser.add_argument('-n', '--developerName', action="store", required=True, dest="devname", help="Developer name. This information is in the provisionign profile")
parser.add_argument('-P', '--provisioningProfile', action="store", required=True, dest="ProvisioningProfile", help="Provisioning Profile path")

Puis sous forme de récupération de valeur :

DeveloperName = args.devname
ProvisioningProfile = args.ProvisioningProfile

Et maintenant ?

Maintenant, cela a peu de chance de fonctionner. Il manque ce pour quoi nous nous sommes lancés dans cette aventure, la gestion de la keychain.
Nous avons besoin de :

• la keychain
• son mot de passe

Deviner quoi ? Nous allons ajouter ces deux éléments à la liste de ceux qui sont attendus dans la ligne de commande.

Gestion des paramètres

parser.add_argument('-k', '--keychain', action="store", required=True, dest="keychain", help="Path to the keychain file")
parser.add_argument('-K', '--keychainPassword', action="store", required=True, dest="keychainPassword", help="keychain's password")
keychain = args.keychain password = args.keychainPassword

Et la fonction qui ouvre et passe la keychain en keychain par défaut.

 def openKeychain(password, keychain):
  cmd_array=(["/usr/bin/security","unlock-keychain", "-p", password, keychain])
  try:   subprocess.check_call(cmd_array)
  except OSError as e:
   logger.debug("Error in %s, exiting"% " ".join(cmd_string))
   writeToSTDERR("Error, please see the log file")
  sys.exit(1)

  cmd_array=(["/usr/bin/security", "default-keychain","-d","user", "-s", keychain])
  try:   subprocess.check_call(cmd_array)
  except OSError as e:
   logger.debug("Error in %s, exiting"% " ".join(cmd_array))

Cette définition est à mettre avant les appels aux fonctions et l’appel lui-même avant l’appel à compileAPP.

La suite, la suite, la suite

Avant de la passer à la suite… faisons un bilan, histoire de voir les plus lents recoller au peloton.
Notre script se compose ainsi :

• Import des modules
• gestion des paramètres de la ligne de commande
• définition du logger
• fonction d’ouverture de la keychain
• fonction de création du dossier de destination
• fonction de compilation .app
• fonction de transformation .app en .ipa
• définition de certaines variables
• appel de la fonction de création du dossier de destination
• appel de la fonction d’ouverture de la keycahin
• appel de la fonction de compilation .app
• appel de la fonction de transformation .app en .ipa

Que manque t’il ?

Pour être distribué notre .ipa a besoin de :

• un fichier manifest.plist qui décrit la méthode de distribution et ses paramètres
• un fichier html qui contient le lien de téléchargement

Commençons par le fichier manifest.plist

Celui-ci peut être généré depuis notre script python en prenant les paramètres dans notre .ipa grâce au module plistlib. Le fichier .ipa étant un fichier zip, il est nécessaire d’avoir aussi le module zipfile. Enfin, pour réaliser l’extraction nous utilisons le module shtuil. Trois lignes de plus dans notre section import.

import zipfile
import plistlib
import shutil

Pour créer ce fichier, deux fonctions sont nécessaires. La première va extraire du fichier .ipa le fichier Info.plist (une plist binaire). La deuxième va transformer cette plist binaire en un plist texte et en extraire les informations dont nous avons besoin.

Extraction du fichier Info.plist

def retrieveInfo(targetFolder,target):
  zin=zipfile.ZipFile("/%s/%s.ipa"%(targetFolder,target)) # definiton du fichier zip
  logger.debug(zin)

  for item in zin.namelist(): # parcours des fichiers contenus dans le zip
    if fnmatch.fnmatch(item, '*/Info.plist'): # recherche du fichier Info.plist
    filename = os.path.basename(item)
    filename = "/%s/%s"%(targetFolder,filename)
    inFile = zin.open(item)
    outFile = file(filename, "wb")

    shutil.copyfileobj(inFile,outFile) # extraction du fichier
    inFile.close()
    outFile.close()
  return filename

Création du fichier manifest.plist avec les éléments extraits d’Info.plist

def createManifest(info,target,targetFolder,deployment_address):
  xmlfile="/%s/%s.xml"%(targetFolder,target)

# we need to convert Info.plist into a xml file (by default it's a binary plist)
  cmd_array=(["/usr/bin/plutil", "-convert", "xml1", "-o", xmlfile, info])
  subprocess.Popen(cmd_array).wait()
  infoPlistFile = open(xmlfile, 'r')
  app_plist = plistlib.readPlist(infoPlistFile)
  os.remove(xmlfile)
  manifestFilename='/%s/manifest.plist'%(targetFolder)
  manifest_plist= {
   'items' : [    {
           'assets' : [
               {
                   'kind' : 'software-package',
                   'url' : urlparse.urljoin(deployment_address, target + '.ipa'),
               }
            ],
            'metadata' : {
                'bundle-identifier' : app_plist['CFBundleIdentifier'],
                'bundle-version' : app_plist['CFBundleVersion'],
                'kind' : 'software',
                'title' : app_plist['CFBundleName'],
            }
      }
   ]
}
plistlib.writePlist(manifest_plist, manifestFilename)
return manifestFilename

Le fichier html

Dans le fichier html nous devons indiquer l’url de distribution de notre application. Il va falloir ajouter ce paramètre à la liste de ceux que nous lisons déjà de la ligne de commande.

 parser.add_argument('-d', '--deploymentAddress', action="store", required=True, dest="deploy", help="Deployment Address, used in manifest.plist file")
...
deployment_address = args.deploy

Et créer une fonction pour générer le fichier html (index.html sera sont nom). Nous allons faire un modèle et remplir certains éléments avec le contenu de variables. Une autre fonction appelle celle de création du fichier html avec les bons paramètres.

def fillHTML(app_name,manifest):  manifestPath="%s%s"%(deployment_address,manifest) # définition du chemin vers le fichier manifest SUR LA MACHINE DE DÉPLOYEMENT
template_html="""
<!DOCTYPE html PUBLIC "-//WC3/DTD HTML 1.0 Transitional/EN" "http://www.w3c.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns=&quot;http://www.w3.org/1999/xhtml&quot;>

<head>

<meta http-equiv=&quot;Content-Type&quot; content=&quot;text/html; charset=UTF-8&quot; />

<meta name=&quot;viewport&quot; content=&quot;width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0&quot;>

<title>[BETA_NAME] - Beta Release</title>

<style type=&quot;text/css&quot;>

body {background:#fff;margin:0;padding:0;font-family:arial,helvetica,sans-serif;text-align:center;padding:10px;color:#333;font-size:16px;}

#container {width:300px;margin:0 auto;border:2px solid #000;border-radius:15px; box-shadow:4px 4px 4px gray;}

h1 {margin:0;padding:0;font-size:14px;}

p {font-size:13px;}

.link {background:#ecf5ff;border-top:1px solid #fff;border:1px solid #dfebf8;margin-top:.5em;padding:.3em;}

.link a {text-decoration:none;font-size:15px;display:block;color:#069;}

</style>

</head>

<body>

<div id=&quot;container&quot;>

<h1>Dear testers</h1>

<div class=&quot;link&quot;><a href=&quot;itms-services://?action=download-manifest&amp;url=[DEPLOYMENT_PATH]&quot;>Tap here to install<br />[BETA_NAME]<br />On Your Device</a></div>

<p><strong>Link didn't work?</strong><br />

Make sure you're visiting this page on your device, not your computer.</p>

</body>

</html>
"""
  TEMPLATE_PLACEHOLDER_NAME = '[BETA_NAME]'
  TEMPLATE_PLACEHOLDER_DEPLOYMENT_PATH = '[DEPLOYMENT_PATH]'
  template_html = string.replace(template_html, TEMPLATE_PLACEHOLDER_NAME, app_name)
  template_html = string.replace(template_html, TEMPLATE_PLACEHOLDER_DEPLOYMENT_PATH, manifestPath)
  return template_html

def createIndexHTML(targetFolder,target,manifest):
  indexFilename = '/%s/index.html'%(targetFolder)
  manifest=os.path.basename(manifest)
  indexFile = open(indexFilename, 'w')
  indexFile.write(fillHTML(target,manifest))
  return indexFilename

Les fonctions createManifest et createIndexHTML sont appelées après la transformation .ipa.

Quoi d’autre

Il nous manque une chose importante pour que notre script soit complet, la copie des fichiers .ipa, index.html et manifest.plist sur la machine de distribution.

Nous allons faire cela par SSH en supposant que la connexion sur la machine de distribution est possible pour l’utilisateur jenkins (souvenez-vous, c’est lui qui va faire tourner le script de build).

Il existe plusieurs modules qui permettent de faire du SSH avec Python. Je n’ai toutefois pas réussi a les faires fonctionner. C’est pourquoi je me suis rabattu sur cmd_array et subprocess.check_call.

def distribution(server, user, password,distantFolder,sourceFolder):
  cmd_array=(["/usr/bin/scp", "-r", "%s/*"%(targetFolder),  "%s@%s:%s"%(user,server,distantFolder)])
  try:
   subprocess.check_call(cmd_array)
  except OSError as e:
   logger.debug("Error in %s. Exiting"% " ".join(cmd_array))
    logger.debug("ErrorString == %s ErrorNum == %d"% (e.strerror,e.errno))

Pour finir ce long billet

Reprenons l’architecture de notre script et voyons ce que nous y avons ajouté :

• Import des modules
• gestion des paramètres de la ligne de commande
• définition du logger
• fonction d’ouverture de la keychain
• fonction de création du dossier de destination
• fonction de compilation .app
• fonction de transformation .app en .ipa
• définition de certaines variables
• appel de la fonction de création du dossier de destination
• appel de la fonction d’ouverture de la keychain
• appel de la fonction de compilation .app
• appel de la fonction de transformation .app en .ipa
• création du manifest.plist
  • Extraction du fichier Info.plist du .ipa
• création du fichier index.html
• copie des fichiers sur la machine cible

Notre script est désormais terminé. Dans un prochain billet, nous verrons comment y introduire deux ou trois fonctionnalités supplémentaires.

Vous pouvez télécharger ce script.

xcodebuild-wrapper.py de Jacques Foucry est mis à disposition selon les termes de la licence Creative Commons Paternité – Partage à l’Identique 3.0 non transposé.

Vous pouvez également retrouver ce script sur GitHub.

Nous allons aussi faire de l’intégration continue. À chaque commit notre Mac OS X va récupérer les sources, les compiler et rendre le résultat disponible pour une installation sur un iDevice.

Maintes commandes de cette installation réclament des droits d’administration. Il est donc nécessaire de faire ces manipulations avec un utilisateur ayant les droits d’administration sur le Mac cible.

Java

Jenkins utilise Java. Par défaut Java n’est pas installé sur Lion. Nous devons donc l’installer par nous même. Heureusement Apple nous propose une image.

# curl -O http://supportdownload.apple.com/download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/Mac_OS_X/downloads/041-1941.20111108.6wtg7/JavaForMacOSX10.7.dmg

Une fois le téléchargement terminé nous allons monter l’image disque téléchargée

# hdiutil attach JavaForMacOSX10.7.dmg
 Checksumming Driver Descriptor Map (DDM : 0)…
 Driver Descriptor Map (DDM : 0): verified CRC32 $148850C9
 Checksumming (Apple_Free : 1)…
 (Apple_Free : 1): verified CRC32 $00000000
 Checksumming Apple (Apple_partition_map : 2)…
 Apple (Apple_partition_map : 2): verified CRC32 $4460C6D3
 Checksumming Macintosh (Apple_Driver_ATAPI : 3)…
 Macintosh (Apple_Driver_ATAPI : 3): verified CRC32 $F1E8BA9E
 Checksumming (Apple_Free : 4)…
 (Apple_Free : 4): verified CRC32 $00000000
 Checksumming disk image (Apple_HFS : 5)…
 ...................................................................................................................
 disk image (Apple_HFS : 5): verified CRC32 $2796E2B9
 Checksumming (Apple_Free : 6)…
 (Apple_Free : 6): verified CRC32 $00000000
 verified CRC32 $5A6B6640
 /dev/disk2 Apple_partition_scheme
 /dev/disk2s1 Apple_partition_map
 /dev/disk2s2 Apple_Driver_ATAPI
 /dev/disk2s3 Apple_HFS /Volumes/Java for Mac OS X 10.7

C’est dans /Volumes/Java for Mac OS X 10.7 que nous trouverons le paquet à installer.

# cd /Volumes/Java For Mac OS X 10.7
# ls
JavaForMacOSX10.7.pkg

Il faut utiliser la commande installer pour réaliser l’installation

# sudo installer -pkg JavaForMacOSX10.7.pkg -target /

L’intégration continue

Au même titre que le développement Agile, l’intégration continue est achement à la mode. Le principe est simple. Un robot (en l’occurrence jenkins) tourne sur une machine d’intégration. Il récupère les sources depuis un gestionnaire de source, réalise les compilations du produit. Le but est de vérifier que le dernier commit n’a pas cassé la compilation. En cas de problème le développeur responsable de l’erreur est alerté du problème.

Il est donc nécessaire d’avoir un système de gestion de source, un mac, un accès SSH sur ce mac et les outils développeurs installés sur ce mac. Nous auront aussi besoin d’Apache, le serveur Web. Ce dernier est installé par défaut sur Mac OS X, nous n’aurons que la configuration du produit à faire.

Installation de Jenkins

L’installation de Jenkins est plus que simple. Il suffit de récupérer sur le site le paquet conçu pour Mac OS X…

$ curl -O http://jenkins.mirror.isppower.de/osx/jenkins-1.451.pkg

et de l’installer avec la commande éponyme :

$ sudo installer -pkg jenkins-1.451.pkg -target /

Création de l’utilisateur Jenkins

Pour amoindrir le risque de trou de sécurité, Jenkins ne doit pas tourner avec un utilisateur ayant de trop grands privilèges. C’est pourquoi nous devons créer un utilisateur spécifique pour cette tâche.

sudo dscl . create /Users/jenkins
sudo dscl . create /Users/jenkins PrimaryGroupID 1
sudo dscl . create /Users/jenkins UniqueID 300
sudo dscl . create /Users/jenkins UserShell /bin/bash
sudo dscl . create /Users/jenkins home /Users/Shared/Jenkins/Home/
sudo dscl . create /Users/jenkins NFSHomeDirectory /Users/Shared/Jenkins/Home/
sudo dscl . passwd /Users/jenkins

Il faut prévenir jenkins qu’il possède maintenant un utilisateur pour fonctionner. Cela se fait dans le fichier /Library/LauchDaemons/org/jenkins-ci.plist. Ce fichier provient du paquet que nous avons installé.
À la fin du fichier se trouve la définition de l’utilisateur responsable de jenkins :

<UserName>
<daemon>

Changez simplement daemon par jenkins avec votre éditeur de texte préféré.

Changeons également le propriétaire du répertoire Jenkins :

# sudo chown -R jenkins /Users/Shared/Jenkins

Il est temps de relancer le service avec les nouveaux paramètres.

Nous allons utiliser les mécanismes prévus par Apple et configurés par Jenkins (et nous), launchd

sudo launchctl unload -w /Library/LaunchDaemons/org.jenkins-ci.plist
sudo launchctl load -w /Library/LaunchDaemons/org.jenkins-ci.plist

Si tout va bien, vous devriez trouver dans /var/log/system.log la ligne suivante :

Feb 27 11:53:32 macmini org.jenkins-ci[37647]: INFO: Jenkins is fully up and running

Signifiant ainsi que votre jenkins est opérationnel.

Reste à tester la connexion vers la console Jenkins. Pointez votre navigateur vers l’adresse IP de votre serveur, sur le port 8080. Vous devriez obtenir quelque chose qui ressemble à cela :

Jenkins, SSH et Git

Pour utiliser git avec jenkins, il est nécessaire d’avoir une clef SSH. Il faut donc générer une clef SSH (en fait une paire de clefs, un privée que vous devez garder secrète et une publique qui sera envoyée sur le serveur git).

SSH

Cette clef doit appartenir à jenkins, il faut donc être jenkins pour générer cette paire de clefs :

# su - jenkins
 # ssh-keygen -t dsa
 Generating public/private dsa key pair.
 Enter file in which to save the key (/Users/Shared/Jenkins/Home//.ssh/id_dsa):
 Created directory '/Users/Shared/Jenkins/Home//.ssh'.
 Enter passphrase (empty for no passphrase):
 Enter same passphrase again:
 Your identification has been saved in /Users/Shared/Jenkins/Home//.ssh/id_dsa.
 Your public key has been saved in /Users/Shared/Jenkins/Home//.ssh/id_dsa.pub.
 The key fingerprint is:
 48:e0:09:7a:da:9e:67:e0:8c:25:fe:bd:9c:de:2f:e4 jenkins@macmini.local
 The key's randomart image is:
 +--[ DSA 1024]----+
 | . . |
 | . o o |
 |. . o . |
 | + . . |
 |o + . S |
 |.B o . |
 |..= o o |
 | .oo oE |
 | ..*..o. |
 +-----------------+

Il n’est pas prudent du tout d’avoir une clef sans passphrase. Toutefois, dans le cas d’un service qui doit tourner indépendamment, c’est le seul moyen de faire.

Pour que plus tard nous puissions récupérer les sources via ssh et git il est nécessaire de préparer le terrain.

Toujours en étant jenkins, il faut que nous tentions de nous connecter à la machine qui contient nos sources.

Pour des raisons de sécurité, il est préférable d’avoir un utilisateur dédié sur la machine qui contient les sources. En fonction de sa nature la commande pour créer cet utilisateur peut être différente. Sur un linux il y a de grande chose que ce soit useradd.

% sudo useradd -m jenkins

Donnez un mot de passe à cet utilisateur :

% sudo passwd jenkins
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Tant que vous êtes connectés sur la machine Linux, profitez-en pour devenir Jenkins afin de créer dans le répertoire de cet utilisateur le dossier

.ssh

.

% su - jenkins
Password:
$ pwd
/home/jenkins
$ mkdir .ssh
$ exit
logout

Il faut maintenant mettre la clef publique de jenkins dans les fichiers de configuration SSH de l’utilisateur jenkins SUR LA MACHINE cible :

# cat .ssh/id_dsa.pub | ssh jenkins@source.example.com "cat - >> /home/jenkins/.ssh/authorized_keys2"

Vous devez connaitre le mot de passe de l’utilisateur sur cette machine.

Ensuite vous devriez pouvoir vous connecter directement sur cette machine

# ssh jenkins@source.example.com

Git

Nous devons installer un greffon pour utiliser git avec jenkins.
Depuis l’écran d’accueil, sélectionnez Manage Jenkins > Manage Plugins et choisissez l’onglet Available. La liste est très longue (vous pourrez explorer la liste des greffons une fois que votre installation de départ fonctionnera). Dans rubrique « Source Code Management » vous devriez trouver « Git Plugin ». Cochez la case et cliquez sur « Downlaod now and install after restart ».

Fastoche non ?

Créer un flux pour XCode

Notre but est de créer un flux de compilation pour XCode. C’est donc ce que nous allons faire maintenant en commençant par préciser d’où viennnent les sources.

Depuis l’écran d’accueil, sélectionnez New Job. Nous allons donner un nom à notre flux et choisir de faire un free-style software project

Mettez une description si vous le désirez (cela peut être utile quand vous avez beaucoup de flux de compilation).

Commençons par indiquer à Jenkins où trouver les sources nécessaire à la compilation du projet. Dans la rubrique SCM, choisissez Git et donnez l’url de votre dépôt. Pensez à mettre le nom de l’utilisateur sur la machine cible, vers lequel vous avez installé la clef ssh de jenkins.

Passons maintenant à la rubrique Build qui, comme son nom l’Indique, va nous permettre de décrire comment doit être construit notre projet.

Dans le menu déroulant sélectionnez Execute Shell. Cela fait apparaitre un champ de saisie. Nous allons y mettre les lignes de commande a exécuter pour contruire notre projet xcode. Il s’agit de la commande xcodebuild.

Sauvez votre flux. Cela vous fait retourner à la page d’accueil.

Celle-ci vous indique que n’avez pas de workspace (espace de travail). Celui-ci sera crée avec le premier lancement d’un flux.

Il est donc temps de lancer la première compilation automatique en cliquant sur Run a build.

Mise au point

Forcément votre premier lancement devrait échouer. Il y a des nombreuses explications possibles. Voyons ce qu’il m’est arrivé pour que vous puissiez avoir quelques pistes.

En cliquant sur le numéro de build dans le cadre build history, vous aurez accès au fichier de trace.

• Impossible de cloner le projet.
• En étant jenkins (su – jenkins) essayer de faire ce clone à la main :

git clone ssh://jacques@source.example.com/data/repositories/monprojet

• Error performing command: git tag -a -f -m Jenkins Build #6 jenkins-Test_XCode-6
• Votre git n’est pas complèment configuré sur la machine qui fait tourner jenkins, il faut au moins donner un nom et une adresse email

git config --global user.email "you@example.com"
git config --global user.name "Your Name"

• You have not agreed to the Xcode license agreements, please run xcodebuild standalone from within a Terminal window to review and agree to the Xcode license agreements.
• Toujours en étant jenkins, lancez xcodebuild sans argument et lisez le contrat xcode. Suivez les instructions pour accepter la licence.

Si tout se passe bien, vous devriez voir une pastille bleue dans le cadre build history

Sur le papier, ça semble terrible… Pas besoin d’admin pour gérer des machines, simple à mettre en œuvre, extensible, peu cher (faut voir)…

Seulement, voilà, la récente affaire de MegaUpload nous apprend qu’il faut faire des sauvegardes, même de ce que l’on met dans le cloud. De nombreux utilisateurs honnêtes du site déjà cité se retrouvent le bec dans l’eau parce qu’ils ont trop fait confiance aux fournisseurs.

Même si OVH ou Amazon sont très loin de la réputation sulfureuse de MegaUpload, un malheur est vite arrivé (faillite, décision de justice…)

Pensez-y avant de sauter le pas.

Lion Server et le VPN PPTP ne font pas bon ménage, du moins dans l’interface de Server Admin. Yoann a creuser la documentation et crée un outil pour configurer le VPN sous Lion Server.

Vous trouverez tous les détails sur son blog

C’est le moment de reprendre les bonnes habitudes du deuxième jeudi de chaque mois : CocoaHeads.

Tous les détails, comme à l’accoutumé sont sur le site cocoaheads.fr.

Et les retardataires iront directement dans le bureau du proviseur !

Mais si, souvenez-vous. Je vous avez donné deux astuces pour incrémenter et décrémenter des chiffres dans un texte avec Vim et les raccourcis CTRL+x (pour incrémenter) et CTRL+a (pour décrémenter).

comments.vim utilise aussi CTRL+x pour dé-commenter. Du coup on perd la fonctionnalité de base VIm. Il va falloir éditer le fichier de définition des raccourcis de comments.vim changer la combinaison de touche.

Il faut éditer le fichier ~/.vim/plugins/vim.comments. Pensez à en faire une sauvegarde avant !

Dans mon fichier, aux lignes 101 et 103 on trouve la définition de la combinaison de touches pour dé-commenter :

" key-mappings for un-comment line in normal mode
noremap  <silent> <C-X> :call UnCommentLine()<CR>
" key-mappings for range un-comment lines in visual <Shift-V> mode
vnoremap <silent> <C-X> :call RangeUnCommentLine()<CR>

Il suffit de changer le X par la lettre que vous désirer utiliser pour ce raccourci. J’ai choisi le M.

On sauvegarde, on relance Vim et hop, ça marche !

En plus de la coloration syntaxique, ce greffon apporte d’autres fonctionnalités intéressantes.

Création du squelette de l’implémentation

À partir d’un fichier header .h cocoa.vim est capable de générer le squelette de l’implémentation dans le fichier .m.

Il est nécessaire que le fichier dans lequel vous allez utiliser cette fonctionnalité soit reconnu comme un fichier d’implémentation, soit donc un .m. Une fois cette formalité accomplie, passez en mode commande et tapez :BuildMethods.

- Si votre fichier d’implémentation porte le même nom que votre fichier, header la génération est simple et immédiat  ;
- si votre fichier d’implémentation ne porte pas le même nom que votre fichier header vous devez le préciser dans la commande :

:BuildMethods monBeauFichier.h

Magique non ?

Note

Il est possible que malgré tout vous ayez du mal à vous faire respecter par Vim et ce greffon. Il faut s’assurer que les éléments qui le constituent sont bien lus au lancement de Vim. Pour ce faire on dispose du fichier ~/.vimrc. Dans celui-ci on va forcer quelques paramètres. Voici le mien, très court en réalité :

filetype plugin on
filetype on
source ~/.vim/ftplugin/objc_cocoa_mappings.vim

- La première ligne indique qu’il faut utiliser la version greffon de filetype au lieu de celle par défaut ;
- la seconde active la détection du type de fichier en cours d’édition ;
- la troisième force le chargement des fonctions additionnelles de cocoa.vim.

Une fois le fichier créé, cocoa.vim devrait mieux fonctionner.

Liste des méthodes et saut à l’une d’entre elles

Un fichier d’implémentation comporte de nombreuses lignes de code et de nombreuses méthodes. En avoir la liste est important.

Passez en mode commande et tapez :ListMethod. La fenêtre se découpe alors, avec en bas la liste des méthodes. Déplacez votre curseur sur celle qui vous intéresse et faites un retour chariot. Magie encore, vous voici sur la première ligne de cette méthode.

Commentaires

Un autre greffon intéressant à mettre en place est vim.comments. Il permet, grâce à deux raccourcis clavier (CTRL-C et CTRL-X) de commenter ou dé commenté des lignes de code. Ce greffon n’est pas limité à Objective-C, il peut être utilisé pour du shell script, du php, du html… En fait, il n’est pas conçu pour l’Objective-C, il va nous falloir le modifier quelque peux pour le faire fonctionner.

L’installation

Copiez simplement le fichier comments.vim dans ~/.vim/plugin.

Avant d’aller plus loin, tester la présence de votre greffon en éditant un fichier source et en testant les raccourcis. Si vous éditez un fichier .m le commentaire sera un #. C’est normal, souvenez-vous que nous allons devoir personnaliser le script de ce greffon.

Personnalisation

Pour personnaliser le script, nous allons l’éditer, avec Vim par exemple :

$ vim ~/.vim/plugin/vim.comments

Nous allons ajouter la même chose en quatre endroits. L’ajout à faire est || file_name =~ '\/m$' .
Ligne 110 :

if file_name =~ '\.cpp$' || file_name =~ '\.hpp$' || file_name =~ '\.java$' || file_name =~ '\.php[2345]\?$' || file_name =~ '\.C$'

devient

if file_name =~ '\.cpp$' || file_name =~ '\m$' || file_name =~ '\.hpp$' || file_name =~ '\.java$' || file_name =~ '\.php[2345]\?$' || file_name =~ '\.C$'

La même modification est à faire sur les lignes 175, 220 et 285.

Les commentaires du fichier sont très clairs et doivent vous guider si vous êtes perdus.

Il est possible de commenter une ligne, mais aussi un bloc… Il suffit de sélectionner les lignes du bloc… Et la question qui suit doit être : »Et comment on sélectionne un bloc gros malin  ? ». Facile, avec le raccourci qui va bien.

Positionnez le curseur à l’emplacement de début ou de fin du bloc, utiliser le raccourci SHIFT-V et déplacez vous, vers le haut ou vers le bas jusqu’à l’autre borne de votre groupe et appliquez le raccourci de commentaire.

Complétion

Un atout majeur pour Xcode4, c’est la complétion, Et là, il faut dire qu’il va être très dur à battre. En effet, Xcode apprend votre code au fur et à mesure que vous le tapez pour augmenter son dictionnaire de complétion. Pas vraiment possible avec Vim. Toutefois avec le greffon cocoa.vim on trouve un fichier de snippets. Celui-ci se trouve dans ~./vim/snippets/objc.vim.

En regardant ce fichier on se rend compte que imp<TAB> est remplacé par #import "fichier.h".

Je vous laisse explorer ce fichier, le comprendre et pourquoi pas mettre vos propres snippets de complétion.

Attention, pour que la complétion fonctionne, il est nécessaire d’installer un autre greffon, snipMate.
.

Deux derniers petits trucs (pour aujourd’hui)

Vim (gvim, et MacVim aussi) supporte les onglets. Il suffit de le lancer avec l’option -p. Personnellement j’ai fais un alias dans on fichier .bashrc :

alias vim='vim -p'
gvim ='gvim -p'
mvim='mvim -p'

Vous êtes en train d’éditer un fichier .m et vous avez besoin d’ouvrir un fichier inclus (ou importé), il suffit de placer sur la ligne d’inclusion du fichier et d’utiliser le raccourci CTRL-W gf.

CTRL-W ouvre un nouvel onglet et gf pour go file.

Conclusion

Avec ces quelques greffons, extension de Vim, nous avons un environnement d’édition de fichier Objective-C qui n’a pas grand-chose à envier à Xcode4.