An installation of Discourse

The Gallery
18

Additional notes on remixing:

  • I just found out that node_modules is copied over, so it’ll be easier if you wait for the project you’re remixing to finish their installation. You should be able to visit the source projects’ web URLs to see if they’re up, which if they’re up, then they’ve finished installing. Avoid remixing during installation, because then you’ll get a copy that’s partially installed, and my scripts aren’t fancy enough to work through that case.
  • In the frontend project, create services/discourse/down before filling in .env so that it doesn’t waste memory and CPU when you’re doing it. Glitch also restarts the project when you change .env, so it makes it easier for runsv to pick up the new down file. I’ve updated the instructions to reflect this.
  • I’ve updated the instructions so that you don’t do any cds other than in subshells. I think this will make writing these notes easier.
  • In the frontend project, ./init.sh runs a database migration, which takes a long time. If it fails partway due to network flakiness, run this from the same terminal to retry it:
    (cd node_modules/discourse && bundle exec rake db:migrate)
    I have a copy of the finished structure.sql in the project and copied into the discourse directory. If you’re up for an experiment, try bundle exec rake db:setup instead of the ... db:create and ... db:migrate in init.sh.
  • In the frontend project, if you’ve done all the steps and puma is ready with this in top:
    runsv discourse
 `- puma 5.0.4 (tcp://0.0.0.0:3000) [discourse]
     `- puma: cluster worker 0: xxx [discourse]
    and the ‘App Status’ button still shows a spinner, and the project still shows some kind of ‘waking up’ page, and there’s no wait-for-ports.sh running, try running refresh in the terminal. I don’t know why this happens sometimes, but it seems we can make Glitch forget that it’s broken.
  • I fixed a couple of dumb things in the frontend project that would prevent these steps from working even if you did everything right. (1) It turns out that, while the contents of .data isn’t copied on remix, the existence of the .data directory propagates. So that mkdir .data is now a mkdir -p .data :woman_facepalming:. (2) That horrible thing in package.json to rm the pidfiles would crash and burn on the first run when there are no leftover pidfiles to delete. It’s a rm -f now :woman_facepalming:.

Thanks to the testers who have been working to smooth out these remixing instructions.