Livraisons (ancienne page)
Cette page est un guide à destination des développeurs.
Duniter est livré sous la forme de différents binaires pour les environnements Linux et Windows :
-
Duniter Desktop
- Pour Debian (.deb)
- Pour Linux (archive tar.gz)
- Pour Windows (.exe)
-
Duniter Server
- Pour Debian (.deb)
- Pour Debian ARM (.deb)
La réalisation de ces livrables ainsi que leur mise à disposition est totalement automatisée. Les sections suivantes décrivent cette procédure.
Pré-requis
N'importe qui peut réaliser la livraison de Duniter, c'est-à -dire produire et mettre à disposition les livrables précédemment cités, sous réserve de réunir les conditions suivantes :
- ĂŠtre administrateur de l'organisation Duniter sur GitHub
- Disposer d'une machine Linux avec :
- 4Go de RAM minimum
- Bash
- Node.js v6+
- VirtualBox
- Vagrant
- Git
- Yarn
Création d'un token GitHub
Pour créer la release GitHub et téléverser les livrables, les scripts de livraison s'attendent à trouver un jeton d'authentification dans le répertoire ~/.config/duniter/.github
.
Pour obtenir un tel jeton, rendez-vous à l'adresse https://github.com/settings/tokens puis générez un nouveau jeton en cochant la case « public_repo ».
Copiez alors le jeton généré, par exemple b23ab3cbe624a8552545900d781a1779b928aa90
, puis enregistrez ce jeton :
echo -n 'b23ab3cbe624a8552545900d781a1779b928aa90' > ~/.config/duniter/.github
Procédure
1. Cloner Duniter et installer ses modules
git clone git@github.com:duniter/duniter.git
cd duniter
yarn
2. Créer une nouvelle version
Cette opération se réalise sur n'importe quel branche, selon le besoin :
- Pour une release, utiliser la branche
master
- Pour une pre-release, utiliser la branche
dev
SĂ©lectionnez la branche :
git checkout master
Une fois positionné sur la bonne branche, lancez le script de changement de version. Par exemple pour passer en version 1.2.3
:
./release/new_version.sh 1.2.3
Poussez les modifications sur le dépôt :
git push origin master --tags
A ce stade, le code source de Duniter est monté en version, et un nouveau tag a été ajouté au dépôt. GitHub est au courant, et reflète une entrée dans les releases à cette occasion. Toutefois la release n'existe pas encore.
N.B: Si la version doit se faire sur la branche
dev
, remplacez simplementmaster
pardev
dans les commandes ci-dessus.
3. Créer la pré-release
Cette fois, nous allons créer la release avec le status pre-release. Ce statut permet de produire la release sans que celle-ci soit visible officiellement jusqu'au moment où l'on décidera que « tout est bon ».
Pour produire la pre-release et l'ensemble des livrables (hors ARM), toujours pour notre version d'exemple 1.2.3
:
./release/new_prerelease.sh 1.2.3
Cette procédure est longue et se résume en 3 étapes :
- Création de la pré-release sur GitHub
- Production des livrables
- Téléversement des livrables produits, sur GitHub
La 1ère étape est quasi-instantannée, mais la production et le téléversement sont longs : le script va produire des machines virtuelles Ubuntu et Windows afin d'y réaliser les livrables finaux. Puis, le téléversement peut prendre du temps selon le débit disponible sur votre connexion Internet.
4. Valider la release
Vous pouvez alors consulter les livrables sur la page releases du dépôt GitHub. Après avoir contrôlé que l'ensemble des fichiers sont bien présents, il est possible de valider la release via :
./release/set_release.sh 1.2.3 rel
La pre-release passera alors en release, et les utilisateurs seront alertés du changement via Duniter UI (dont disposent Duniter Desktop ou Duniter Server démarré en webstart
). La page d'accueil https://duniter.org/fr affichera Ă©galement cette nouvelle version.
5. Le build ARM
À partir du moment où l'étape 2. a été réalisée (depuis x86 ou ARM, peu importe), il est possible de lancer le build ARM.
Il suffit de réaliser les opérations 1. et 3. sur ARM. Le livrable sera alors produit et uploadé avec les autres versions.
Une bonne pratique est donc de démarrer les étapes 1., 2. et 3. sur un poste Linux 64bits, puis de lancer les étapes 1. et 3. sur ARM en parallèle. Il existera alors 2 machines apportant leur concurrence à la construction de la release.
Étapes à suivre avec une raspbian:
- utiliser une release « jessie » pour garantir que ceux qui sont sous cette version peuvent installer le package
- installer yarn, voir la page https://yarnpkg.com/lang/en/docs/install/Â :
curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add - && echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list && sudo apt-get update && sudo apt-get install yarn
- attention, yarn désinstalle automatiquement le nodejs préinstallé avec raspbian parce qu'il n'est pas compatible, il faut donc installer node :
sudo apt-get install curl && curl -sL https://deb.nodesource.com/setup | bash - && sudo apt-get install -y nodejs
- s'assurer que le package zip est installé (il ne l'est pas par défaut)
- avoir mis correctement le fichier correspondant à votre jeton github dans .config/duniter/.github (voir « création d'un token github » plus haut)
- avoir installé votre authentification ssh pour github, voir par exemple https://help.github.com/articles/connecting-to-github-with-ssh/. Typiquement, il vous suffira de copier le contenu du répertoire .ssh de votre profile dans le profile du raspberry. Attention, in faut faire un chmod 400 sur id_rsa sinon github se plaint.