Donc, nous ne parlons pas du déploiement d’instance avec db, etc.
Existe-t-il un modèle pour maintenir une instance en utilisant un format déclaratif ? Catégories, tags, politiques, etc. Je pensais que ce serait bien pour nos utilisateurs techniques de recommander des changements via PR plutôt que des fils de discussion et une exécution manuelle, mais je n’ai pas vu de plugin ou d’autre outil “as code” axé sur la configuration organisationnelle de Discourse.
Je pense que l’on s’attend à ce que les sites utilisent la catégorie pré-remplie Site feedback pour cela. Sa description est : « Discussion sur ce site, son organisation, son fonctionnement et comment nous pouvons l’améliorer ».
C’est une idée intéressante. Quel avantage cela aurait-il par rapport au simple fait que les utilisateurs suggèrent des changements dans des discussions régulières ? L’objectif est-il d’avoir un moyen de suivre les changements apportés à la configuration du site au fil du temps ?
Les paramètres du site, les catégories, les tags, les politiques, etc., peuvent être configurés avec l’API Discourse. Il serait possible d’avoir un script qui gère la configuration de votre site via l’API dans un dépôt git. Le script pourrait être exécuté lorsqu’une PR sur le dépôt est acceptée. De mon point de vue, ce serait plus difficile que de faire manuellement des changements dans la configuration du site via l’interface utilisateur.
10-4 sur la catégorie. Pour l’instant, je faisais un peu de crowdsourcing sur un modèle existant. Pour moi, il s’agit d’obtenir l’engagement communautaire de style GitOps, donc j’ai atterri avec celui-ci, mais je peux le transférer à l’autre si cela peut aider.
Et oui, nous utilisons un peu la configuration en tant que code pour beaucoup de choses, vous obtenez donc le contrôle de révision propre, le retour arrière déterministe, la revue claire des changements, etc. Les changements basés sur l’interface graphique ne sont pas mauvais (et ce que nous faisons aujourd’hui via les boucles de rétroaction communautaires), mais c’est une opération manuelle et le contexte de décision peut être perdu avec le temps. Et les constructions organisationnelles existent au milieu entre l’infrastructure et le dialogue réel, donc ce n’est pas une chose de déploiement ou de réhydratation.
Et oui, les déclencheurs basés sur les PR (ou même un problème) peuvent déclencher un runbook qui détermine le changement proposé et effectue l’opération. Faire l’analyse des différences et le linting peut être difficile, c’est pourquoi j’ai cherché à voir si quelqu’un avait déjà essayé. La demande est définitivement dans le camp des “nice to have” et ne pourrait résonner qu’avec une certaine démographie.
J’aimerais (et je suis tout à fait certain que notre communauté de langages de programmation aimerait) absolument cette fonctionnalité. En particulier, j’aimerais pouvoir gérer les thèmes, les composants et les textes du site sur un dépôt GitHub où les gens peuvent facilement soumettre des pull requests. Les paramètres généraux du site seraient également bienvenus, mais ce sont ces trois éléments qui sont les plus difficiles à maintenir dans une interface web.
Si ce n’est pas possible aujourd’hui — et je ne pense pas que ce soit le cas, du moins pas pour une instance payante/hébergée — est-ce que cela pourrait être reclassé en demande de fonctionnalité ?
Immédiatement après avoir écrit cela, j’ai pensé à vérifier l’interface utilisateur. Il semble que ce soit possible — du moins pour créer/importer un thème à partir d’un dépôt git ! Comment cela fonctionne-t-il pour les mises à jour ? Est-il capable de récupérer de nouveaux commits ? J’ai trouvé Installing a theme from a private Git repository, mais cela ne discute pas de la mise à jour.
Est-il possible de convertir un thème ou un composant existant pour qu’il suive un dépôt git ?
Vous pouvez exporter un thème, le téléverser dans un dépôt, puis l’installer.
Tous les thèmes distants ont une section en haut où vous pouvez décider si vous souhaitez qu’il se mette à jour automatiquement lorsque Discourse est mis à jour. De plus, il existe une tâche d’arrière-plan qui vérifie si une version plus récente est disponible, et vous pouvez également rechercher manuellement de nouvelles mises à jour. Lorsqu’une nouvelle version est disponible, le bouton propose de mettre à jour le composant.
Vous pouvez également trouver ces informations dans le guide sur Installing a theme or theme component.
Au cas où vous ne l’auriez pas encore trouvé, il existe également un tutoriel sur le développement de thèmes
C’est super, merci @Moin ! Cela couvre deux sources majeures de personnalisation de notre site.
J’aimerais toujours vraiment utiliser git pour gérer les Textes du site car beaucoup d’entre eux (comme les directives, la FAQ, etc.) sont longs, non triviaux, et peuvent être open source pour la contribution et la révision de la communauté.
Les autres paramètres du site seraient bienvenus, mais certainement pas aussi cruciaux.
Ceux-ci sont généralement basés sur un sujet dans la catégorie du personnel. Je pense que vous pouvez les déplacer vers une catégorie différente et faire du message un wiki. Ensuite, vos membres pourront les modifier.
Vous pouvez également utiliser les paramètres du site FAQ URL, Privacy policy URL et ToS URL et les héberger ailleurs.
Oui, mais le paramètre URL de la FAQ a malheureusement d’autres comportements qui rendent son utilisation très contre-productive à cette fin.
Juste pour signaler qu’il est clair qu’il est déjà possible de gérer le contenu dans le contrôle source, jetez un œil à ce sujet, il est maintenu sur GitHub :
en bas :
bien que je ne sois pas sûr si cette fonctionnalité a déjà été publiée ou annoncée (ou si c’est l’intention).
J’ai commencé à expérimenter avec une action GitHub qui soumet des mises à jour à la section site_texts du panneau d’administration via l’API. C’est assez rudimentaire pour le moment (et échoue pour les grandes valeurs avec un 422 pour une raison quelconque), mais c’est prometteur.
A certainement besoin de plus de travail.
