jbbarth's corner

L’info est déjà disponible au fond d’une page du wiki Redmine, ici. Je vais faire exactement pareil, parce que c’est bien. Et comme j’ai envie de faire un article technique, je mets ça ici.

Voilà donc en très bref la config que j’ai utilisée pour linker mon Redmine (prochainement en ligne, dès que les bons DNS seront propagés) à mon dépôt github pour Simplelog (rien mis encore dessus, seulement la release officielle).

$ sudo mkdir -p /var/redmine/git_repositories
$ sudo chown rails:rails /var/redmine/git_repositories
$ cd /var/redmine/git_repositories
$ git clone —bare git://github.com/jbbarth/simplelog.git
$ crontab -e
        #git repo for simplelog
        */15 * * * * git-pull /var/redmine/git_repositories/simplelog/ 2>&1 | grep -vE "^From|FETCH_HEAD|^Already up-to-date"

J’avais évoqué ici la synchronisation de dépôts Git (en l’occurrence Github mais ça n’a pas d’importance).

Mais voilà, ça ne fonctionnait plus tout à fait après migration de serveur, et ce n’était pas très clair pour moi honnêtement. Alors j’ai de nouveau regardé sur le wiki de Redmine et trouvé cet article qui décrit les choses très bien.

Seule différence, j’utilise les branches sous Git, et ce mode ne synchronise que la branche principale (“master”, ce que l’on appellerait le “trunk” sous subversion).

Initialisation de mon dépôt:

cd /var/redmine/git_repositories/
git clone —bare git@github.com:jbbarth/project.git project
cd project
git remote add origin git@github.com:jbbarth/project.git
git fetch -v

Ajout de ceci en CRON:

#sync of my github repos for redmine
*/10 * * * * /var/redmine/git_repositories/sync_repositories.sh >/dev/null

Et le petit script qui va bien:

#!/bin/sh

base=$(dirname $0)
[ "$base" == "." ] && base=$(pwd)

cd $base
for repo in $(ls -F |fgrep "/"); do
  cd $base/$repo
  git fetch origin
  for branch in $(ls refs/remotes/origin/); do
    git reset —soft refs/remotes/origin/$branch
  done
done

Youpi!

En ce moment j’ai trop d’articles techniques à publier, souvent trop en bazar, ou trop long pour être publiés dans une demi-colone de ce blog. De plus je risque de quitter mon boulot dans quelques mois, et tout ce que j’ai pû documenter là-bas sera perdu pour moi si je ne le récupère pas avant. Bref, j’ai besoin d’un wiki, simple d’utilisation, avec suivi des révisions, formatage en Textile, un peu comme celui de Remine.

Une contrainte supplémentaire, qu’il soit en Ruby on Rails, éventuellement Merb. Pas par idéologie, croyance en REST, ou quelconque connerie de ce genre (et certains en tiennent une couche à ce niveau quand on voit la liste rails-france), mais plutôt parce que j’en ai marre de maintenir 50 technos hétérogènes sur mon serveur. Mon blog, mon gestionnaire de projets tournent déjà en Rails. Ce sera bientôt le cas du site chanmasters.com que je réécris en ce moment. Bientôt le cas également de ma gallerie de photos, qui tourne déjà avec des scripts ruby mais pas administrable en mode web. Donc dommage pour Dokuwiki qui a priori me convenait parfaitement…

J’ai essayé Instiki sans être réellement convaincu, je ne saurais pas bien expliquer pourquoi. Et puis, j’aurais des modifs à faire dessus pour qu’il me convienne (templates trop épurées à mon goût, affichage “geeky” de certains champs, etc…). Ce qui implique un petit peu d’exploration du code, cf la suite. Je n’ai pas trouvé d’autres projets très actifs en Rails et qui me convienne (liste ici)…

En fait, le wiki de Redmine me convient parfaitement. Facile à “hacker” (je commence à connaître un peu le code même si je suis loin d’être un gourou comme les 3 ou 4 grands contributeurs réguliers), maintenu, communauté active, support de textile entre autres, jolis diff, etc. Nickel, à 4 petites choses près :

1. le support Textile est un peu foireux parfois ; voir ici
2. la coloration syntaxique est hideuse, j’aimerais bien remplacer CodeRay par autre chose ; voir ici
3. j’aimerais bien que les hiérarchies soient faites automatiquement, quitte à rendre l’arborescence un peu profonde, pas grave ; voir ici
4. j’aimerais bien un système de tags avec un nuage sur le côté ; voir ici, ici et ici

Bref, ça sent bon, et le choix est tout fait ; je documenterai dans le prochain article l’installation et la configuration de Redmine pour me servir de wiki :-)

Ce post fait suite à celui-ci.

Tout d’abord, on installe Redmine classiquement ; je passe volontairement les aspects DNS (création d’un sous-domaine, en l’occurence wiki.jbbarth.com), Apache (création du vhost), et “système” (script de démarrage de Mongrel, user et port adéquats, ce genre de choses) :

cd /home/app/jbbarth/
svn co http://redmine.rubyforge.org/svn/trunk _redmine-0.8-wiki
ln -s _redmine-0.8-wiki wiki
cd wiki/
rake db:migrate
rake redmine:load_default_data
rake config/initializers/session_store.rb

Après démarrage, on procède à une configuration basique de Redmine :

• modification du user/pass admin
• configuration générale dans Administration > Settings
• création d’un projet public “wiki”, identifiant “wiki” ; tous les trackers décochés, et tous les modules sauf le module “wiki”
• dans ce projet, on configurera la “Start page”, et surtout on la créera/remplira (sous peine d’avoir des erreurs 404 dans la suite)

Là commencent les choses “sérieuses”. Que voulons-nous ?

1) que l’accueil de Redmine se fasse sur la page de démarrage du wiki du projet “wiki”
Pour cela, nous allons éditer config/routes.rb, et remplacer l’accueil défini à la ligne “map.home” par :

  #map.home '', :controller => 'welcome'
  map.home '', :controller => 'wiki', :id => 'wiki'

Après redémarrage de l’instance, ça fonctionne !

2) suppression des liens inutiles pour un wiki ; en particulier la première tab “Overview/Aperçu”, et “Projects/Projets”, “My page/Ma page” et “Help/Aide” dans le menu en haut à gauche (nous n’aurons qu’un seul projet “wiki”)
Pour cela nous allons créer un thème à nous et cacher ces liens via du CSS, ce qui me parait bien suffisant : ils ne représentent aucun “danger”, c’est juste qu’ils perturbent la navigation dans le cadre d’une utilisation wiki-only. Voir donc ici pour la création d’un nouveau thème, et éventuellement ici pour des exemples de thèmes.
Nous créons donc un thème “wiki”, puis quelques lignes suffisent à la fin de public/themes/wiki/stylesheets/application.css :

/* Specific to wiki */
#top-menu .my-page, #top-menu .projects, #top-menu .help { display:none; }
#main-menu .overview { display:none; }

3) passage des patches cités dans l’article précédent

cd /home/app/jbbarth/wiki/
mkdir patches

a) passage de CodeRay à UltraViolet :

wget -P patches http://www.redmine.org/attachments/download/1698/syntax_highlighting.diff
patch -p0 < patches/syntax_highlighting.diff
wget -P patches http://www.redmine.org/attachments/download/1699/redcloth.diff
patch -p0 < patches/redcloth.diff
wget -P patches http://www.redmine.org/attachments/1700/ultraviolet_highlighter.zip
cd patches/
unzip ultraviolet_highlighter.zip
cat ultraviolet_highlighter/README.txt
apt-get install libonig-dev
gem install ultraviolet
cp -a ultraviolet_highlighter ../vendor/plugins/
cd ..

Les traductions ne sont pas bien passées, donc on édite à la main config/locales/en.yml et fr.yml, et on supprime les fichiers “.rej” correspondants.
b) pages parent automatiques :

wget -P patches http://www.redmine.org/attachments/download/2082/3108_automatic_parent_with_tests.diff
patch -p0 < patches/3108_automatic_parent_with_tests.diff

c) correction d’un petit bug de Redcloth :

wget -P patches http://www.redmine.org/attachments/download/1728/redcloth_arobas.diff
patch -p0 < patches/redcloth_arobas.diff

d) système de tagging :
Il y avait un patch proposé ici, mais il ne correspond pas vraiment à ce que je veux. Voici quand même une méthode pour l’appliquer sur une copie de travail SVN :

wget -P patches http://www.redmine.org/attachments/download/2060/wiki_page_categories_20090520.patch
sed -i -e 's#- redmine.orig/#- #g' -e 's#\+ redmine/#+ #g' -e 's#diff.*\.orig/\([^ ]*\).*#Index \1\n===============================================#g' patches/wiki_page_categories_20090520.patch
patch -p0 < patches/wiki_page_categories_20090520.patch
rake db:migrate

Après toutes ces modifs, on se rend compte que certains patches ne sont pas bien passés :

find . -iname "*.rej"

Normalement avec cet ordre de passage des patches, il n’y a que lib/redcloth3.rb dont on résoud les conflits à la main.

Voilà, hormis le système de tagging on a un wiki fonctionnel. Je ferai un nouveau post si je trouve quelque chose pour le support des tags. Il ne reste plus qu’à le remplir maintenant !

EDIT
- pour que l’activité du projet prenne en compte les changements du wiki par défaut : éditer lib/redmine.rb, et modifier autour de la ligne 155/156:

-  activity.register :wiki_edits, :class_name => 'WikiContent::Version', :default => false
+  activity.register :wiki_edits, :class_name => 'WikiContent::Version', :default => true

- la même option permet que les recherches prennent en compte les entrées du wiki sur le projet courant
- pour cacher la liste déroulante de sélection des projets dans la recherche : édition de public/themes/wiki/stylesheets/application.css, ajout de :

select#scope { display:none; }

EDIT2
J’ai changé l’ordre de passage des patches pour avoir le moins de choses possibles à résoudre à la main.

Je travaille en ce moment sur des plugins Engines pour Redmine. Ces plugins me serviront au boulot, et permettront de laisser une situation un peu plus propre que les bidouillages actuels à mon départ. En particulier en avançant sur le plugin de gestion d’un datacenter (site et dépôt github), j’apprends énormément de choses sur le fonctionnement de Rails/Redmine/Engines, et j’entame donc une série d’articles sur ces découvertes. Ces articles supposent d’avoir déjà lu le tutoriel du site, et je repartirai souvent de cet exemple.

Cela donnera certainement lieu à des entrées dans le wiki redmine.org ou des suggestions dans les tickets. Et puis ça m’astreindra à publier un peu, comme le fait Eric dans ses Daily Refactor du core Redmine depuis 3 semaines et pour les mêmes raisons, et aussi suite à cet article de Damien.

Allons-y.

init.rb : on y ajoute la clé et la valeur par défaut du paramètre qu’on veut introduire, par exemple ici “boolean_parameter”. On précise également un partial qui permettra de gérer les paramètres du plugin :

  settings :default => { :boolean_parameter => true },
           :partial => 'settings/my_plugin'

app/views/settings/_my_plugin.html.erb : on place ici un formulaire pour gérer nos paramètres. Il sera automatiquement accessible dans la partie Administration > Plugins > lien “Configurer” sur votre plugin. “plugin_my_plugin” est à remplacer dans ce qui suit par “plugin_[nom de votre plugin]” :

<p>
  <label>Paramètre booléen</label> 
  <%= check_box_tag 'settings[boolean_parameter]', 1,
                    Setting[:plugin_my_plugin][:boolean_parameter] %>
</p>

Et voilà ! Ensuite, n’importe où dans votre plugin, vous pourrez utiliser :

Setting[:plugin_my_plugin][:boolean_parameter]

En réalité en mettant “1” comme deuxième paramètre, vous ne stockerez pas un booléen, mais “1” (coché) ou “nil” (décoché). Si vous souhaitez obtenir “true” ou “false” absolument, vous pouvez utiliser :

!!Setting[:plugin_my_plugin][:boolean_parameter]

A voir en vrai ici