Is this correct? How long to install dev Version?

I am trying to install Discourse dev version on a Ubuntu 20.04 droplet in DO for the sole purpose of migrating a FluxBB forum to Discourse, exporting, and then importing to a production version of Discourse.

I had no problem installing the Docker production version as a test (without migrating from FluxBB).

However when I try to install the dev version of Discourse using this guide:

I find that it never completes when I run this command:

bundle exec rake autospec

After something like 30min of waiting for it to finish I get timed out of my remote session.

Also I get tons of errors, unfortunately I don’t have them handy but they are all of the type that some function is always returning “nil”.

And since I don’t know what that command does or if it is necessary (the instructions just say “try running the specs” without saying what this does or why to do it) I went ahead and tried the next command:

bundle exec rails server --binding=0.0.0.0

And I am finding that this takes forever also and spits a bunch of stuff out in the Terminal that I don’t understand, maybe it’s errors and maybe it isn’t.

So my question is, is this expected behavior or am I doing something wrong? Roughly how long would one expect for it to take these commands to complete?

And is it possible to just migrate the FluxBB forum using the production/Docker version of Discourse without having to use the dev version? Right now I don’t even have a production site yet, so I’m not worried about breaking it, I can blow it up & recreate it at will.

1 Like

That means the server is running. And of course, it will continue to run unless and until you hit control C or close the terminal.

Information is printed to the terminal ad infinitum unless you stop the server.

Within a few seconds of that running the web page will be available at your browser.

Are you connecting on the right port in your browser? Usually this is 3000.

1 Like

There arw several howto topics about running imports in production servers. You might use one of those as a guide for running the script you want to run.

It does sound like you’ve installed the development environment and that you should run the script there.

1 Like

Not seeing anything in the browser. I see a ruby process running if I run ‘top’ from terminal.

If the Terminal output just runs on and on forever after running

bundle exec rails server --binding=0.0.0.0

should that not be made explicit in the documentation? Usually when I do a how-to guide I expect a command to do something and finish and display information saying that the install is done and I’m good to go.

1 Like

There arw several howto topics about running imports in production servers.

Where might these be located? The only one I see for FluxBB explicitly says to do it on a development install:

I guess it’s considered common sense that if you start a web server it is not intended to stop unless the admin wants it to. Web servers generally are meant to serve pages day after day after day … but sure someone could add that clarification. Anyone can submit proposed improvements to the guide via PR.

1 Like

But is it common sense that that command starts a web server? It just says rails server, which doesn’t have to be a web server. When you start an apache web server you’re returned immediately to the command prompt, it doesn’t spew stuff in Terminal endlessly…

Rails is a web application framework. I don’t think it’s fair to directly compare it to Apache.

I happen to like the fact you can see it busy working. When it stops, something is usually wrong! The output can be useful in some circumstances, especially in dev. You can change the amount of information displayed using environment configuration.

btw, Rails can be ‘daemonized’, according to the docs, with the -d switch. Feel free to dig into why that doesn’t appear to function in the vanilla install, there may be a limitation it introduces. The Team are best to talk to that.

1 Like

Hey @epsteindidnt

When you get into the swing of Rails development, you will, if you are like me, find that what you describe as " spew(ing) stuff in Terminal endlessly" becomes one of your best friends.

For example, I’m currently developing a Rails application for a client where we are transforming all their legacy business logic (from many decades ago) to Rails. I actually bought a new monitor just so I can see the "stuff in Terminal endlessly" (your words), because that information is shiny gold to a developer.

In addition to the amazing Rails server log, providing intricate details of what is going on, there is also another “developer’s best friend”, the Rails console!

When I write code for Rails, I basically write the draft in VSC and then I copy-and-paste snippets into the Rails console to make sure everything works as expected.

When debugging, I write Ruby print(like) statements (p, puts) into the code and observe what happens in the “endless stream of gold rails server log information” on the screen. Almost all my errors are fixed in this way! Like I said, I recently bought a new standalone curved gaming monitor just to see the Rails server log info you are annoyed with :slight_smile:

It sounds to me, reading your posts, that you are a bit like me at the beginning of this year, migrating to a Rails application without prior Rails development experience. In the beginning, I also felt annoyed about Rails (maybe more than) a bit; and now 9 months later, I develop exclusively in Rails everyday for clients (my limit is 1/2 time client work since I’m semi-retired) and have stopped all prior PHP dev work. Honest, I have a new found passion for Rails (and Ruby), very much. Better late than never, as the saying goes!

Regrading Apache2, Apache does not provide the intricate details of what is going in behind the scenes in an application like Rails does. I run Apache2 as a reverse proxy in front of all my Rails applications and to be frank, I cannot remember the last time I looked at an Apache log file; because I do all the debugging using the Rails server log you are currently annoyed with :slight_smile:

In closing, I honestly hope a different perspective from a prior “migrate a forum to Rails person” helps in some small way. For me, being compelled to get off LAMP web apps and on to Rails web apps, was one of the best “tech things” that happened to me (personally) in 2020.

Happy Holidays!

1 Like

I’ve been a little freaked out by this lately too. Here’s what I realised today:

The output in a rails s terminal will show a bunch of querying on start-up, but then it also includes output from discourse’s sidekiq jobs (at least it does in the docker dev set-up). So if you’re running a really big import, then you’ll be getting a really a big sidekiq queue of post-processing jobs which might run for ages afterwards. I think these are non-essential jobs e.g. loading caches, which don’t seem to prevent you browsing the site before they’re finished.

This was confusing the hell out of me because I did a big import, then backed out of that and re-initialised the database to do a tiny test import, and it was still endlessly churning away doing querying related to the no-longer-existing big database! The solution was to empty the sidekiq queues using a rails console.

Too late to help you, but thought I’d share that.