Je travaille sur gitpod.io, un IDE gratuit en un clic pour GitHub. Nous utilisons actuellement Spectrum pour notre communauté, mais nous rencontrons quelques problèmes avec celui-ci et nous aimerions déployer une instance Discourse pour l’essayer et éventuellement migrer.
Si possible, nous souhaiterions utiliser notre compte Google Cloud à cette fin. Pourriez-vous s’il vous plaît m’orienter dans la bonne direction ? Par exemple, le nouveau Google Cloud Run est-il un bon choix pour héberger une instance Discourse ?
De plus, puisque notre mission est d’automatiser entièrement tous les environnements de développement (du moins pour les projets open source), je souhaite contribuer à une configuration entièrement automatisée de Discourse, permettant aux contributeurs de démarrer un environnement Discourse prêt à coder en ligne en un clic (plutôt que de parcourir de longues listes d’instructions d’installation et d’installer/configurer manuellement un grand nombre de dépendances sur leur appareil actuel). J’ai déjà commencé à travailler sur cela en me basant sur l’excellente configuration automatisée de Discourse pour Janitor de @notriddle (salut !).
Je rencontre cependant actuellement un problème, car récemment les instructions de configuration échouent en raison de l’absence de la table « polls ». Je ne sais pas encore comment résoudre cela, mais je continuerai à enquêter. Je pensais simplement le mentionner ici.
C’est possible, mais ce n’est pas si simple. Discourse n’est pas un conteneur sans état, ce pour quoi Google Cloud Run est conçu. Par conséquent, vous devrez prévoir un moyen d’ajouter un volume persistant pour les données conservées par Discourse (téléversements, avatars, base de données).
Je recommanderais plutôt une instance Google Compute standard, et c’est tout. Avec un script ou des outils de gestion d’infrastructure, vous devriez pouvoir automatiser le déploiement de nouvelles instances Discourse. Ce guide Install Discourse on Ubuntu or Debian for Development pourrait également vous aider.
Quelles instructions de configuration utilisez-vous ? Si la table « polls » est manquante, cela suggère que vous n’avez pas exécuté les migrations du plugin. Elles devraient être exécutées automatiquement en mode développement. En mode test, vous devez ajouter LOAD_PLUGINS=1 avant la commande rake db:migrate
Cela semble plus raisonnable que d’utiliser Cloud Run, car extraire tout l’état des conteneurs Discourse pourrait prendre un certain temps. Merci de m’avoir orienté vers le guide ! Je vais essayer de le suivre pour configurer une instance Compute et revenir ici avec mes résultats.
== Seed from /workspace/discourse/db/fixtures/990_settings.rb
Discourse hostname: localhost is not a valid domain for emails!
== Seed from /workspace/discourse/db/fixtures/990_topics.rb
rake aborted!
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "polls" does not exist
LINE 8: WHERE a.attrelid = '"polls"'::regclass
^
Merci beaucoup pour l’astuce ! Je vais essayer cela et revenir ici également. (Désolé d’avoir posé deux questions en une ! J’espère que cela ne rendra pas la discussion trop confuse.)
L’installation pour les développeurs est beaucoup plus lente et conçue pour… le développement. Vous voudrez donc suivre les instructions d’installation standard. Il est assez facile de l’automatiser. Mon service d’installation est désormais entièrement automatisé (sauf les paramètres DNS requis par Mailgun, car je n’ai pas le contrôle sur les DNS du client).
La partie la plus difficile de l’installation est la configuration de la messagerie.
De plus, l’installation et la maintenance sont deux choses différentes.
Merci @pfaffman ! Désolé pour la confusion, j’ai mélangé deux choses dans mon message initial : 1) installer Discourse pour la communauté Gitpod, et 2) automatiser la configuration de développement pour les développeurs et contributeurs de Discourse. Heureusement, je suis le guide de développement pour le point 2), pas pour le 1).
== Seed from /workspace/discourse/db/fixtures/990_settings.rb
Discourse hostname: localhost is not a valid domain for emails!
== Seed from /workspace/discourse/db/fixtures/990_topics.rb
rake aborted!
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "polls" does not exist
LINE 8: WHERE a.attrelid = '"polls"'::regclass
^
Ai-je bien compris votre suggestion ? Avez-vous d’autres idées pour résoudre ce problème ? (J’ai essayé de supprimer les tables au préalable, mais cela a échoué avec une erreur différente que je ne me souviens plus. Je suis prêt à réessayer.)
De plus, j’ai oublié de mentionner que mes instructions de configuration fonctionnaient jusqu’à la semaine dernière environ, alors l’erreur est apparue récemment après un rebase de Discourse. Je pense que c’est peut-être après la migration vers Rails 6 ? DEV: Upgrade Discourse to Rails 6 (#8083) · discourse/discourse@32b8a2c · GitHub
Pour information, vous pouvez facilement reproduire l’erreur en essayant d’ouvrir mon fork Discourse dans Gitpod : Dashboard . Vous verrez mon installation automatisée échouer et obtiendrez un environnement interactif où l’on peut essayer diverses commandes Discourse dans le Terminal.
Contrairement au message du commit, je pense que les migrations des plugins fonctionnaient avant ce commit. Elles ne fonctionnent plus. Cela n’a pas d’importance si LOAD_PLUGINS=1 est fourni ou non — les migrations des plugins ne s’exécutent pas dans mon environnement de développement.
J’ai rencontré cette erreur lors de la migration multisite. Sur la base de données dev/test, tout fonctionne bien. Je vais donc l’examiner attentivement aujourd’hui.
Cela devrait faire en sorte que les environnements de développement se comportent correctement lors du suivi des guides.
@kris.kotlarek, peux-tu jeter un coup d’œil à ce commit… pourquoi l’opération dump du schéma → chargement a-t-elle cessé de fonctionner dans Rails 6 avec nos plugins ?
Je pense avoir trouvé le problème lié à ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "polls" does not exist
Lorsque load_config est évalué lors de la création de la base de données, il écrase migrations_paths.
J’ai commencé à déboguer ce code relatif à la population de la base de données de test, mais je me suis perdu. Pour une raison quelconque, après le chargement du schéma, lors de l’appel à db:migrate, Rails souhaite toujours évaluer les migrations et nous obtenons une erreur indiquant que la table existe déjà. Jusqu’à présent, je n’ai pas pu trouver la raison.
Un grand merci pour votre enquête sur ce bug ! Je vais utiliser les instructions mises à jour pour le contourner pour l’instant.
Ah, intéressant, merci ! Je vais examiner les Dockerfiles de développement existants pour voir s’ils peuvent simplement être lancés en un clic par Gitpod. Ce serait cool.
(Mais maintenant, DISCOURSE_DEV_HOST=.gitpod.io bundle exec rails s -b 0.0.0.0 semble entrer dans une boucle de plantage avec :
/workspace/.rvm/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:551:in `load_missing_constant': Unable to autoload constant Version, expected /workspace/discourse/lib/version.rb to define it (LoadError)
et le serveur web a recommencé à bloquer mon URL d’aperçu Gitpod :
Bonjour Jan, si tu as un moment, je suis curieux de savoir quels ont été les problèmes ou ce qui n’a pas fonctionné comme tu l’espérais avec Spectrum ?
Je suis Spectrum depuis un peu, en lisant des articles à leur sujet de temps en temps.
(J’ai essayé de t’envoyer un MP à ce sujet, mais pour une raison quelconque, lorsque je clique sur ton profil, il n’y a pas de bouton pour envoyer un message privé.)
Je vais utiliser les instructions mises à jour pour le contourner pour l’instant.
Ce serait cool.