Journal R.I.P CIA.vc , et maintenant quoi?

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
22
13
mai
2013

J'avais l'habitude quand je travaillais en groupe d'utiliser les services du site CIA.vc afin de disposer sur un channel IRC de travail d'un bot notifiant tous les commits sur le système de version (Mercurial en ce qui me concerne).

Retravaillant en équipe après une pause, je ressentais le besoin de remettre en place un tel système, et quel ne fut pas mon effroi de constater que le site avait mis fin a ses activités, avec pour principale raison "IRC et subversion c'est hazbeen, maintenant c'est Twitter et Github qui sont hype et tendance".

Même s'il y a un peu de vrai la dedans (surtout pour subversion..), je n'ai pas vraiment envie de pousser mes notifications de commit sur Twitter, et j'auto-heberge très bien mes repository, je n'ai pas besoin de Github pour ça. Et vu que ma petite équipe est plus versée vers Gtalk que vers IRC, j'ai donc cherché (pas beaucoup j'admets) une solution a base d'XMPP.

Bon ok, j'avais envie de me changer les idées et d’écrire un petit bot XMPP, voila, j'avoue.

Voila ma solution, en python, utilisant les packages JabberBot , ZeroMQ et Mercurial :

#!/usr/bin/env python

# to make the mercurial hook work... black magic.
from mercurial import demandimport; demandimport.disable()

from jabberbot import JabberBot, botcmd
import sys
import optparse
import zmq

USERNAME = "mybot@jabber.net"
PASSWORD = "d4p455w0rD"
BIND_OPT = "tcp://127.0.0.1:5000"

class SystemInfoJabberBot(JabberBot):
    def idle_proc(self):
        result = self.socket.poll(10)
        if result != 0:
            msg = self.socket.recv()
            for user in self.roster.getItems():
                if user != USERNAME:
                    print "send: ", user, ":", msg
                    self.send(user, msg)

def server():
    print "starting server..."
    bot = SystemInfoJabberBot(USERNAME,PASSWORD)

    context = zmq.Context()
    bot.socket = context.socket(zmq.SUB)
    bot.socket.bind(BIND_OPT)
    bot.socket.setsockopt(zmq.SUBSCRIBE, "")

    bot.serve_forever()

def client(msg):
    print "sending '"+msg+"'"
    context = zmq.Context()
    socket = context.socket(zmq.PUB)
    socket.connect(BIND_OPT)
    socket.send(msg)
    print "message sent."

def hghook(ui, repo, hooktype, node=None, source=None, **kwargs):
    for rev in xrange(repo[node].rev(), len(repo)):
        r = repo[rev]
        message = "["+repo.root+"] "+str(rev)+":"+r.hex()+" by "+r.user()+" : \""+r.description()+"\" "+str(r.changeset()[3])
        client(message)

if __name__ == "__main__":
    parser = optparse.OptionParser()
    parser.add_option('-m', '--message', help='send a message')
    parser.add_option('-s', '--server', action='store_true', help='run as server')
    args = parser.parse_args()

    if args[0].server == True:
        server()
    elif args[0].message:
        client(args[0].message)
    else:
        parser.print_help()

le script est lancé comme daemon sur le serveur avec l'option --server et se comporte comme un bot xmpp et un "receveur" ZeroMQ .

Dans le fichier .hg/hgrc de mon projet, j'ai rajouté:

[hooks]
changegroup = python:/path/to/the/script.py:hghook

Le script peut également être utilise en ligne de commande pour envoyer un message de test avec l'option -m "un message"

Voila, c'est du "home made" vite fait mal fait qui fait tout de même bien le boulot.

Et vous, qu'utilisez-vous pour suivre les commits de vos repository?

  • # Chez Sourceforge

    Posté par  (site web personnel) . Évalué à 1.

    Et vous, qu'utilisez-vous pour suivre les commits de vos repository?

    Ce que fournit Sourceforge, qui est très limité pour git et par conséquent assez mauvais.

  • # KGB

    Posté par  (site web personnel) . Évalué à 10.

    J'ai entendu parler d'un successeur à CIA, qui s'appelle KGB je crois. Sérieusement.

    • [^] # Re: KGB

      Posté par  . Évalué à 8.

      Tout à fait, c'est ce qui est maintenant utilisé sur les chan Debian.
      À ma connaissance, il gère au moins git, svn et cvs (page du projet).

  • # Github+IRC

    Posté par  (site web personnel, Mastodon) . Évalué à 7.

    Mes dépôts étant sur github, j'utilise le bot de github, qui va alors sur le channel IRC du projet.

    Perso, je ne trouve pas IRC hasbeen… Surtout que je ne vois pas en quoi Twitter en serait le remplaçant, vu qu'ils n'ont pas du tout le même objectif. Bref, CIA.vc sont à coté de la plaque.

    • [^] # Re: Github+IRC

      Posté par  (site web personnel) . Évalué à 4.

      Moi non plus je ne trouve pas IRC hasbeen, mais je crois qu'on est bien les seuls. Les jeunes sont élevés a l'instant-messaging, les concepts d'IRC et l’aridité des clients sont complètement aliens pour eux. S'tay mieux a vent, bla bla bla…

      • [^] # Re: Github+IRC

        Posté par  . Évalué à 2.

        Je suis probablement un jeune con, mais IRC ce n'est pas de l'instant messaging ?

        Personnellement, j'ai l'habitu de discuter avec une personne à la fois donc xmpp est plus pratique pour ça (sans empêcher de créer un salon en cas de besoin).

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Github+IRC

          Posté par  (site web personnel) . Évalué à 2.

          J'avoue que la différence est ténue, mais je garde "instant messaging" pour les systèmes orientés "1 a 1" (MSN, ICQ, XMPP, AIM, etc.) et pas pour les systemes orrientes "salons". Je précise bien "orientés" car les deux savent faire l'autre, juste moins bien.

          Or pour un travail en groupe, c'est le mode "salon" qui a du sens (je trouve) , car il est important que tout le monde participe aux conversations qui ont lieux, même entre 2 devs (au du moins tout le monde doit les lires). Et les systèmes de messagerie instantanée favorisent la conversation 1 a 1 et rendent les discussions a plusieurs difficiles a mettre en place et a conserver. Dans mon précédent projet, je me battais contre les discussions 1 a 1 entre devs, qui donnaient de mauvais résultats (décisions moins bonnes, perte de temps, car quand A parle a B et qu'au bout de 30 minutes ils annoncent a tous qu'ils ont décidées X, C s'exclame "ha mais non, on peut pas, a cause de Y" , et op, 30 minutes de perdues). Et pourtant, on était tous sur IRC…

          Si je passe a XMPP sur ce projet la, c'est juste parce qu'on est 2 :)

          • [^] # Re: Github+IRC

            Posté par  (site web personnel) . Évalué à 3.

            Si je passe a XMPP sur ce projet la, c'est juste parce qu'on est 2 :)

            J'ai bossé pendant plus de deux ans sur un projet où on était entre 3 et 6, avec un salon XMPP, ça marche très bien.

            • [^] # Re: Github+IRC

              Posté par  (site web personnel) . Évalué à 2.

              Ok, ça doit être de la résistance utilisateur alors, moi les salons XMPP m'ont toujours paru inutilisables… Sûrement parce que je suis trop habitué a IRC. Enfin du coup ca va pas etre tres complique de tweaker mon bot pour qu'il poste sur un salon XMPP :)

              • [^] # Re: Github+IRC

                Posté par  (site web personnel) . Évalué à 0.

                Je vois pas en quoi les salons XMPP sont inutilables en comparaison à IRC. C'est pas le mode de fonctionnement privilégié mais ça marche bien. Et puis si vraiment t'es un nostalgique d'IRC, il y a des clients qui permettent de faire de l'XMPP depuis un client IRC.

                Au contraire, pour les plus jeunes qui n'ont pas connu IRC, ça évite quand même de devoir apprendre certaines commandes obscures.

              • [^] # Re: Github+IRC

                Posté par  (site web personnel, Mastodon) . Évalué à 3.

                C'est plutôt que tu n'as pas un client qui te convient dans ce cas. Essaye poezio si tu en veux un (bon) qui s'approche d'IRC.

                Techniquement XMPP permet de faire tout ce que permet IRC (et bien plus), je ne vois pas en quoi il serait moins adapté à quoi que ce soit.

    • [^] # Re: Github+IRC

      Posté par  . Évalué à 4.

      Moi je crois que si tu veux suivre un flux de donnée, utiliser un truc stateless comme IRC est étrange. Si t'es pas connecté tu perds les notifications, ca veut dire qu'elle n'étaient pas si importantes que ca…

      Du coup soit j'ai une raison d'avoir les notifications et j'utilise un support adapté (code review, mail, flux RSS ou autre). Soit j'ai pas de raison, et il me suffit de regarder l'historique de mon DVCS .

      • [^] # Re: Github+IRC

        Posté par  . Évalué à 5.

        Moi je crois que si tu veux suivre un flux de donnée, utiliser un truc stateless comme IRC est étrange. Si t'es pas connecté tu perds les notifications, ca veut dire qu'elle n'étaient pas si importantes que ca…

        Je ne crois pas tu veux pouvoir voir si le quelqu'un fait une modif' sur une partie du code qui peu potentiellement impacter celui sur le quel tu es entrain de travailler. Quand tu commence à travailler, tu met à jour tes bases de code donc pas la peine d'avoir les anciennes notifications.

        Du coup soit j'ai une raison d'avoir les notifications et j'utilise un support adapté (code review, mail, flux RSS ou autre).

        Les flux RSS c'est statefull ? C'est nouveau ça.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Github+IRC

          Posté par  . Évalué à 3.

          Je ne crois pas tu veux pouvoir voir si le quelqu'un fait une modif' sur une partie du code qui peu potentiellement impacter celui sur le quel tu es entrain de travailler.

          Et si le mec commit pendant la nuit on retourne à la case départ.

          Sur des petites fenêtre de temps de toute facon tu ne peux rien y faire et tu devras te tapper le merge, donc tu perds ton temps à te faire spamer en IM. Sur des "grandes" fenêtre de temps et pour suivre ce qu'il se passe avoir une UX plus adaptée et moins temps réel me semble un meilleur choix.

          Les flux RSS c'est statefull ? C'est nouveau ça.

          Strictement parlant tu as raison.

          Pratiquement tu configures ton flux pour qu'il contienne suffisement d'entrées pour que tu puisses le considérer comme tel même avec un client basique (pas besoin de 5 ans d'historique).

      • [^] # Re: Github+IRC

        Posté par  (site web personnel) . Évalué à 1.

        Mon use case est un peu le même que Michel: quand je code, je suis connecté. Je veux être notifié instantanément des commits. Quand je me remets a coder après une pause, je pull les changements et le lis les logs, donc je n'ai pas besoin d'avoir les notifs que j'ai ratés. Et je n'ai pas envie de pourrir mes mails…

        • [^] # Re: Github+IRC

          Posté par  . Évalué à 4. Dernière modification le 13 mai 2013 à 19:39.

          quand je code, je suis connecté. Je veux être notifié instantanément des commits.

          J'en vois de moins en moins l'intêret. Fais ton taff. Au pire si ca dure longtemps, tu updates ta branche de référence de temps en temps pour voir les différences. Tu as exactement les mêmes informations et tu les as quand elles t'intéressent.

          Avoir un truc à surveillé, ou tu peux louper des trucs, et qui interrompt ton travail n'apporte pas de plus value. Si je veux savoir si ca à changé il suffit de puller… De toute facon je devrais le faire. Il y avait un interet du temps de subversion, mais avec un VCS moderne je vois plus.

      • [^] # Re: Github+IRC

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        utiliser un truc stateless comme IRC est étrange.

        Non, les utilisateurs qui sont sur IRC, peuvent être informé de suite, en live. Ce n'est pas le cas des flux RSS ou twitter etc, parce que ce n'est pas du "push".

        Je trouve au contraire donc IRC très bien adapté et complémentaire des flux rss ou autre. D'ailleurs sur github il y a un flux RSS des commits, les personnes peuvent demander à recevoir les commits par mail il me semble, ou sinon elles peuvent faire des pulls.

        Bref, utiliser IRC n'est pas étrange.

    • [^] # Re: Github+IRC

      Posté par  (site web personnel) . Évalué à 1.

      Perso, je ne trouve pas IRC hasbeen…

      A la rigueur, ce qui peut parfois remplacer IRC c'est des choses comme HipChat ou Campfire par exemple.
      Pour HipChat par exemple, pas besoin de s'embêter avec des histoires de log, plus ou moins persistant, plus ou moins complet, etc. Et ça c'est bien (d'avoir les logs tout le temps, persistant, etc).

      Et sinon utilisez ZNC pour faire office de proxy, backlog, etc, c'est devenu ma seule et unique façon d'accéder à IRC :-)

      Mais dans tous les cas Twitter ne remplace absolument pas tout ça.

    • [^] # Re: Github+IRC

      Posté par  (site web personnel) . Évalué à 2.

      J'avais trouvé le bot de github assez nul car il faisait un join/quit à chaque fois, et en plus il n'avait pas de couleurs. C'est toujours le cas ?

  • # irker

    Posté par  . Évalué à 3.

    Il y a irker, une sorte de relais IRC par ESR. Le code est franchement pas joli, mais ça marchotte.
    http://www.catb.org/esr/irker/

    • [^] # Re: irker

      Posté par  (site web personnel) . Évalué à 1.

      J'utilise irker, c'est très simple à mettre en œuvre quand on s'héberge soi-même ; par ailleurs, je l'utilise pas que pour les commits.
      Et ensuite, c'est le seul qui m'a permis d'avoir un filtrage encore plus puissant que celui fourni par CIA.

      Le code ne respecte pas trop les conventions Python, mais en dehors de ça, je ne le qualifierai quand même pas de moche (mais peut-être parce que j'en suis un petit contributeur).

      • [^] # Re: irker

        Posté par  . Évalué à 2.

        C'est surtout que la gestion des connexions est / était atrocement pourrie.
        (on a eu des problèmes sur Freenode à cause de ça, il y avait des tas de connexions en rafale parfois)

  • # La version bérurienne

    Posté par  (site web personnel, Mastodon) . Évalué à 7.

    Moi j'utilise SàT (étonnamment ;) ).

    en gros mon /etc/mercurial/hgrc.d/hooks.rc c'est ça:

    [hooks]
    incoming.sabot = /srv/bin/hg_sabot_hook.sh
    
    

    et mon /srv/bin/hg_sabot_hook.sh c'est ça

    #!/bin/sh
    
    #we first make sure that D-Bus is launched
    eval `/srv/bin/dbus-launch.sh`
    
    #and we set PYTHONPATH
    export PYTHONPATH=$PYTHONPATH:/home/goffi/lib
    
    PWD=`pwd`
    PROJECT=`basename $PWD`
    
    PROJECT_FULL=$PROJECT #if the full name is not in the following list, we use the basename
    
    case $PROJECT in
            bellaciao ) PROJECT_FULL="Bellaciao";;
            gcp ) PROJECT_FULL="GCP";;
            libervia ) PROJECT_FULL="Libervia";;
            lm ) PROJECT_FULL="List Movies";;
            sat ) PROJECT_FULL="Salut à Toi";;
            sat_media ) PROJECT_FULL="SàT media";;
            sat_pubsub ) PROJECT_FULL="SàT PubSub component";;
            sat_website ) PROJECT_FULL="SàT WebSite";;
            urwid_satext ) PROJECT_FULL="Urwid SàT Extension";;
    esac
    
    hg log -r $HG_NODE --template "Commit from {author|person} on $PROJECT_FULL\n{desc}" | /home/goffi/sat_bots/sat/frontends/src/jp/jp -p sabot sat@chat.jabberfr.org
    
    

    La partie importante étant bien sûr la dernière ligne. jp est l'interface en ligne de commande (je mets le chemin complet), sabot c'est le nom du profil du bot (un compte a été créé avec l'interface en ligne de commande, comme n'importe quel compte, et c'est le profil « sabot »), et l'argument est le jid du salon.

    À noter que si tu veux publier sur identi.ca, IRC, ou des saletés propriétaires, il te suffit d'utiliser un transport (comme spectrum).

  • # ruĝamia

    Posté par  (site web personnel) . Évalué à 4.

    Et vous, qu'utilisez-vous pour suivre les commits de vos repository?

    J’utilise ruĝamia http://dev.louiz.org/projects/rugamia (que j’ai fait moi-même), qui a pour but de pouvoir annoncer les commits d’un dépôt git sur un salon XMPP, mais aussi de s’intégrer un peu à redmine.

    C’est expliqué sur la page du projet, mais pour résumer :
    - Il annonce en temps-réel les commits effectués, avec auteur, message de commit, lien vers le diff disponible sur le redmine, et un joli résumé coloré avec les ++++ et ---- qui indique les fichiers modifiés etc.
    - Possibilité de créer un ticket depuis le salon juste en utilisant !add "title" "the content". À noter qu’il utilise l’API de redmine, donc il faut donner sa clef d’API personnelle au bot, qui créera ensuite les tickets avec le bon utilisateur, sur la forge. On peut aussi autoriser seulement certaines personnes à utiliser cette fonctionnalité, en les passant en member.
    - Annoncer les autres changements sur la forge Redmine (par exemple création ou mise à jour d’un ticket, ou modification d’une page wiki). C’est quasiment codé mais c’est pas encore fonctionnel, il manque pas grand chose. Je terminerai bientôt j’espère.

    Le bot peut se connecter à plusieurs salons et surveiller plusieurs dépôts (chacun étant associé à un salon).
    Notez que ces 3 fonctionallités sont plus ou moins distinctes, et la surveillance de dépôt git est totalement indépendante de redmine, donc on peut n’utiliser que cette fonctionnalité si on le désir.

    Ça utilise SleekXMPP (et bientôt slixmpp http://dev.louiz.org/projects/slixmpp), python3 (et pas python2, qui est presque autant has been que irc et svn), et python3-zmq

    À ma connaissance il n’est utilisé que sur ma propre forge, donc il n’a pas intensivement été testé. Si quelqu’un est intéressé et rencontre des problèmes, n’hésitez pas à me faire des commentaires.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.