D’accord, donc si j’ai déjà un plugin bien développé en mode développement, comment puis-je le transférer en production sans dépendre de services tiers ? Existe-t-il même un moyen de le faire ?
Oui, cela est expliqué dans ce document
Tu plaisantes ? Tout ce tutoriel repose sur GitHub, et ma question porte justement sur le fait de ne pas dépendre de tiers.
Hébergez-le sur GitHub ou GitLab, clonez-le comme d’habitude.
Discourse lui-même dépend de plusieurs services externes comme Github, Docker Hub, Rubygems, le registre NPM et LetsEncrypt. Rendre le déploiement de votre plugin indépendant de Github n’a pas beaucoup de sens, à mon avis.
Oh, tu as raison, j’ai manqué cette partie. 
Cela a du sens car j’ai développé de nombreux petits plugins qui effectuent de petites tâches et n’auront donc pas besoin de mises à jour. Gérer GitHub pour héberger ces petits plugins est excessif, c’est trop de travail.
Mettre un plugin sur GitHub prend moins d’une minute de travail. Créez un dépôt et copiez-collez le script shell qu’il génère lors de la création, qui effectue les commandes git init, git add et git push. C’est la raison pour laquelle vous êtes le premier à poser cette question. Il est également judicieux de placer vos plugins sous contrôle de version, quelle que soit la taille du plugin.
Vous pourriez copier le script d’installation et le modifier afin qu’il copie directement les répertoires de vos plugins dans l’image Docker. Cela suppose que vous ayez déjà le code du plugin localement. Cependant, je soupçonne que maintenir le script d’installation modifié face aux mises à jour qu’il reçoit représente un travail dix fois plus important.
Je ne suis pas le premier à poser la question (d’autres l’ont déjà fait), mais la discussion ne fait que se compliquer, et au final, vous ne répondez jamais vraiment à rien.
Il n’y a aucune justification à cette approche qui ne permet pas de flexibilité. Essayez au moins WordPress ou un autre service une fois, et vous verrez que l’installation de plugins n’est pas le cauchemar que c’est sur Discourse.
Utiliser GitHub c’est bien, mais vouloir travailler localement est-il mal vu ?
Pour être clair : je ne travaille pas pour Discourse.org. Je suis simplement un utilisateur ici, tout comme vous.
Chez Communiteq, nous avons développé notre propre panneau de contrôle qui permet une installation/désinstallation facile des plugins. Fait amusant : il ne remplace pas GitHub, il s’appuie dessus.
Si vous aviez développé (et non installé) un plugin WordPress, vous n’auriez jamais dit cela, car là, c’est vraiment un cauchemar.
L’utilisation d’un contrôle de version approprié vous évitera bien des tracas et des problèmes à l’avenir. Cela protège votre plugin pour le futur et permet de conserver un historique des mises à jour.
Cela offre une approche modulaire pour séparer les responsabilités, réduisant ainsi la complexité.
Cela vous permet de gérer vos instances de manière indépendante, rendant les migrations et les reconstructions de serveur beaucoup plus simples.
C’est également l’approche professionnelle.
Je suis curieux de savoir comment vous avez créé et testé un plugin « bien développé » sans utiliser GitHub ou un autre service de dépôt similaire. Comment avez-vous développé « de nombreux petits plugins » pour Discourse ?
Être conflictuel avec les personnes qui tentent de vous aider ne vous mènera pas loin. Si vous avez déjà développé des plugins comme vous l’affirmez, vous savez que leur installation sur Discourse n’est pas un cauchemar ; utiliser un dépôt et modifier un fichier app.yml devrait être facile pour quelqu’un qui auto-héberge et qui a de l’expérience en développement de plugins.
Je ne sais pas si l’hébergement sur Codeberg devrait fonctionner avec les plugins Discourse. Si c’est le cas, c’est probablement ce que cherche l’auteur du sujet.
Je suis d’accord pour remettre en question l’utilisation de GitHub. Ils ont supprimé environ 300 000 dépôts (liés à des DMCA) sans communication préalable, et la méthodologie de l’étude de la CMU — qui consiste à vérifier si des dépôts précédemment observés ont ensuite été supprimés — suggère que l’ordre de grandeur de dépôts supplémentaires a été retiré via des mesures de conformité internes.
La seule étude de la CMU a révélé environ 14 000 dépôts supprimés lors d’une seule opération de fake-star, contre environ 20 000 à 47 000 par an via le DMCA. Il n’y a pas de métriques globales car ces dépôts affichent simplement des erreurs 404.
Enfin, il n’y a pas de risque réel pour les plugins Discourse, mais Farble est désormais une question de sécurité nationale, et nous ignorions ce qui pourrait arriver à court terme si chaque publication humaine devait être vérifiée par Persona ou un système similaire.
Donc, tu recommandes à l’équipe Discourse de quitter GitHub ?
Il existe plusieurs alternatives et c’est très bien. Utilise-les si tu le dois, mais si tu n’es pas prêt à fournir un petit effort, inconvénient de faire tourner Discourse à mon avis.
Est-ce que c’est ce que vous appelez combatif ? Je suis désolé, mais personne n’a combattu, vous êtes probablement juste trop sensible. Et je m’excuse si cela a sonné combatif.
Quoi qu’il en soit, pour répondre à votre question, je l’ai évidemment fait avec un compte GitHub jetable, mais ils sont si petits que je n’ai pas vraiment besoin de les tester beaucoup ni d’écrire beaucoup de code.
Je les ai déjà installés en utilisant le compte jetable et j’ai vérifié qu’ils fonctionnent, mais à long terme, je ne veux pas avoir à surveiller le dépôt chaque fois que je veux apporter une modification. Je ne plaisante pas quand je dis qu’ils sont très petits. Par exemple, l’un d’eux ajoute simplement un bouton à une page externe sur la page d’accueil, et c’est tout.
C’est comme dire qu’on veut une voiture, mais qu’on n’a pas la peine de faire le contrôle technique annuel.
C’est simplement le coût à payer pour héberger publiquement sur le web ouvert.
Je suis sûr que si vous le souhaitez, vous pouvez trouver un moyen de modifier les scripts d’installation et de créer des liens symboliques depuis un emplacement sur votre serveur, mais vous n’avez pas l’air de vouloir faire le moindre effort, et ce sera à vous d’écrire et de maintenir cette solution.
Si vous parvenez à condenser cela en un composant de thème, vous pouvez recourir à une solution à la Heath Robinson et utiliser discourse_theme pour pousser les modifications depuis votre machine locale vers votre serveur, mais ne vous plaignez pas si votre machine locale tombe en panne, est perdue ou volée, et que vous ne pouvez plus récupérer votre code (sans avoir au préalable déterminé comment extraire une copie live depuis votre serveur).
Encore plus simple si vous ne souhaitez pas installer le gem discourse_theme : les thèmes peuvent être téléchargés sous forme de fichier zip, et vous pouvez construire pas mal de choses directement dans l’interface d’administration.
Et pour le rappeler, sauf si vous travaillez avec Ruby, vous n’avez pas besoin du tout d’un plugin, donc c’est probablement un thème que vous recherchez… aucun besoin de Git.
Bonne remarque ! Mais l’avantage de discourse_theme, c’est la mise à jour instantanée sur place, ce qui vous permet de vérifier rapidement les modifications sans avoir à compresser une mise à jour et à la réimporter.
Ça ressemble plus à quelqu’un qui veut conduire une voiture mais qui ne va jamais à une station-service. « Je vais juste remplir le réservoir avec mes mains nues. ». 
Si tu as utilisé GitHub pour développer les plugins, alors l’utiliser comme source d’installation est trivial. Pousser des modifications vers un dépôt demande moins d’efforts que de transférer manuellement les fichiers de plugin mis à jour vers un serveur.
On dirait plutôt que tu essaies de contourner le processus d’installation pour déployer des plugins sur une installation Discourse hébergée.