Bonjour.
Je suis à la recherche d'une solution wiki relativement simple, et qui permet de se baser sur un repo git pour gérer le contenu.
Je connais wiki.js (qui était utilisé dans une boite dans laquelle j'ai travaillé il y a deux ans). J'ai tenté de l'installer dans la société ou je suis aujourd'hui (via image docker), mais j'ai l'impression que wiki.js ne sait pas aller chercher le code source de ses modules sur internet derrière un proxy - a moins que j'aie raté quelque chose. Du coup j'ai deux questions :
- avez-vous déjà réussi à configurer wiki.js derrière un proxy d'entreprise sans avoir à mettre en place des contournement crades ?
- avez-vous des alternatives à proposer à wiki.js ?
Merci d'avance pour vos réponses.
# Alternative: ikiwiki
Posté par volts . Évalué à 5 (+3/-0).
Ikiwiki est un bon candidat pour cela. C'est déjà présent en paquet pour distribution Debian et dérivée, et même chez Alpine Linux pour faire ses propres images docker.
[^] # Re: Alternative: ikiwiki
Posté par totof2000 . Évalué à 2 (+0/-0).
Il me parait un peu trop rudimentaire (dans l'absolu j'aime bien, mais ça risque de ne pas plaire à d'autres), mais je vais quand même creuser la piste.
# Fossil
Posté par raspbeguy (site web personnel, Mastodon) . Évalué à 3 (+2/-0).
https://fossil-scm.org
Ça fait aussi d'autres trucs que wiki par contre. Pour avoir un aperçu, c'est ce qu'utilise le Salon de Puffy, une communauté OpenBSD francophone.
Un gentil du net
[^] # Re: Fossil
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
En fait Fossil a aussi une fonctionnalité de dépôt. Le wiki est facile à utiliser, il faut connaître la syntaxe Markdown. Mais rien de très complexe.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Fossil
Posté par totof2000 . Évalué à 4 (+2/-0).
Je pense c'est plus un SCM avec fonctionnalité Wiki qu'un wiki avec fonxtionnalité SCM .. :)
[^] # Re: Fossil
Posté par totof2000 . Évalué à 2 (+0/-0).
C'est pas vraiment ce que je cherche : sinon j'utiliserais le wiki de gitlab.
[^] # Re: Fossil
Posté par totof2000 . Évalué à 2 (+0/-0).
Après relecture, je me dis que ma réponse peut-être interprétée comme un peu sèche : désolé si c'est le cas, mais ça n'était pas mon intention : j'ai répondu vite fait parce que j'ai reçu un appel en même temps et j'ai fait vite.
[^] # Re: Fossil
Posté par Cyril Brulebois (site web personnel) . Évalué à 3 (+1/-0).
Tu pourrais peut-être expliquer ce qu'il te manque dans le wiki GitLab, parce que « wiki » et « git » et « mais pas GitLab » c'est une devinette avec vraiment peu d'indices…
Debian Consultant @ DEBAMAX
[^] # Re: Fossil
Posté par totof2000 . Évalué à 2 (+0/-0).
Deux raisons parmi d'autres :
- le wiki gitlab est très orienté projet/groupe alors que je recherche quelque chose de plus global.
- je dois pouvoir partager le contenu du wiki avec des gens qui n'ont pas accès au gitlab.
En gros, mis à part le fait que les pages doivent être stockées et versionnées dans git, il ne doit pas y avoir plus de lien entre gitlab et le wiki.
# Quel usage ?
Posté par madhatter (site web personnel) . Évalué à 1 (+0/-0). Dernière modification le 05 décembre 2024 à 16:40.
Salut totof,
par curiosité et pour peut-être te proposer d'autres solutions qui s'appuient sur Git mais qui ne sont pas des wiki : c'est pour quoi faire ? :)
There is no spoon...
[^] # Re: Quel usage ?
Posté par totof2000 . Évalué à 2 (+0/-0).
L'objectf est de mettre en place de la doc technique, avec une dizaine de personnes en édition, et une population plus large pour la lecture. Il s'agit d'une solution qui ne sera peut-être pas définitive ( pour l'instant c'est un POC), d'ou l'envie d'un truc simple, et je tiens beaucoup au fait que le versionning des pages se fasse sur un repo git.
[^] # Re: Quel usage ?
Posté par madhatter (site web personnel) . Évalué à 3 (+2/-0).
Je me doutais que c'était ça. J'ai été dans la même situation au boulot. ;)
Pour ma part, j'ai mis en place Bookstack. Il est simple à mettre en œuvre et à utiliser et il convient assez bien à une plateforme de doc technique.
Malheureusement il ne répondra pas à ton besoin dans la mesure où il n'est pas capable d'avoir un dépôt Git comme backend de données.
Je pense que ça doit être faisable via l'API et des webhooks mais bon, c'est pas forcément super.
J'avais certaines contraintes « humaines » qui faisaient que j'avais peu de libertés. Il fallait un outil (ultra) simple à utiliser.
Ça a quand même dérivé et c'est malgré tout devenu tout ce que je ne voulais pas : un tas de m**** avec des trucs dans tous les sens, rien de structuré, aucun soin dans les docs rédigées… mais c'est une autre histoire.
Si j'avais à faire un choix aujourd'hui et sans être tributaire de collègues incapables de faire quoi que ce soit sans un éditeur WYSIWYG je ne m'orienterais pas là-dessus. Je prendrais plutôt un générateur de site statique se sourçant sur un dépôt Git, comme le suggère nishiki plus bas.
Avec un peu de recul (c'est le 2e wiki de doc que je gère sur 10 ans), je trouve que le mode wiki n'est pas si adapté que ça. Surtout avec du Git derrière.
Si tu as une équipe à qui le markdown (ou tout autre markup language) ne pose pas de problème, le site statique est à mon sens une meilleure option. C'est plus cadré en terme de mise en forme, tu as encore moins à t'en soucier, la structure est calquée sur celle du dépôt, tu bénéficies du versioning Git et tu peux travailler avec n'importe quel éditeur de ton choix tout en étant compatible avec tout le monde.
Et tu es libre de changer de générateur si tu as besoin sans tout devoir migrer.
There is no spoon...
[^] # Re: Quel usage ?
Posté par totof2000 . Évalué à 3 (+1/-0).
Le bon côté de wiki.js, c'est que tu disposes d'un éditeur de doc (md) qui permet à ceux qui ne savent pas le rédiger à la main de faire de l'édition en mode pseudo wyswig.
En fait le but pour moi c'est que les gens puisent éditer, mais d'avoir de la validation via pull request ou merge request du contenu pour justement éviter que ça parte en vrille. J'aurais deux instances de mon servuer : une instance de prod, et une instance de validation qui pointeraient sur des branches différentes, et l'instance de prod ne permettrait pas l'édition en direct.
# Decap CMS
Posté par Colargol . Évalué à 2 (+0/-0).
Ce CMS se présente comme "Open source content management for your Git workflow"
https://decapcms.org/
# Hugo + Relearn
Posté par nishiki . Évalué à 3 (+2/-0).
Hello,
Pour les documentions j'utilise Hugo avec le thème relearn
Tu peux pousser les pages générées avec ta CI sur n'importe quel hébergement static.
# gitlab
Posté par steph1978 . Évalué à 2 (+0/-0).
Un wiki gitlab est un repo git.
git clone git@mongitlab.net:monorg/monprojet.wiki.gitEnvoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.