The discussion revolves around the need for multiple development instances of Discourse. pfaffman currently switches between branches and database environments to handle different development tasks, finding it inefficient. simon faces a similar issue, wanting to test a network of Discourse sites with DiscourseConnect providers and clients on his local computer. pfaffman suggests that running multiple production sites on a local machine is possible but may require advanced DNS configuration. simon decides to test on production sites instead, due to the complexity of DNS setup.
On my development box, I find myself needing multiple instances. One site I’m importing is on stable, others use importers that I am developing. Right now what I do is when switching jobs, I switch branches in git and run a script that does
It’s really annoying when I’ve, say, run an importer that takes several hours and then want to run it again with updated input (and not have to re-import the whole thing).
Is there something different I should be doing? Perhaps I should run separate instances with Vagrant? Contrive to tell Discourse to use a different database for each different job?
Entschuldigung, dass ich auf ein so altes Thema antworte. Konnten Sie das jemals zum Laufen bringen? Mein Anwendungsfall ist, einige Tests mit der Einrichtung eines Netzwerks von Discourse-Sites durchzuführen, bei denen einige der Sites als DiscourseConnect-Anbieter und andere Sites als DiscourseConnect-Clients fungieren. Ich kann mehrere Produktions-Sites dafür einrichten, aber es wäre großartig, die Sites auf meinem lokalen Computer haben zu können.
Es wird wirklich schwierig sein, DiscourseConnect zum Laufen zu bringen (zumindest als Quelle, die eine URL benötigt) in der Entwicklung. Wenn Sie gut in diesen DNS-Spielen sind (wie z. B. das Routing dieser über Ihre Firewall?), dann hindert Sie nichts daran, mehrere Produktions-Websites auf Ihrem lokalen Rechner auszuführen.