It’s less tutorial and more confessional. I haven’t used Rails much since 4.0 was shiny. So there’s likely some common practice workflow that I don’t know yet. But I got it to work.
Install glitch-soc locally
glitch-soc documentation refers you to Mastodon docs ,
Mastodon’s installation instructions seem focused
on production installations. I bounce back and forth between Mastodon’s
README and its developer documentation.
The README says I need:
$ pamac install redis $ sudo systemctl start redis $ sudo systemctl enable redis
- Version installed
Once again, going off the Arch wiki entry.
$ pamac install postgresql $ sudo -iu postgres > initdb -D /var/lib/postgres/data > exit $ sudo systemctl start postgresql.service $ sudo systemctl enable postgresql.service $ sudo -iu postgres > createuser --interactive Enter name of role to add: random Shall the new role be a superuser? (y/n) y > exit $ createdb random
That reminds me. I want to finish reading The Art of PostgreSQL.
- Version installed
Clone project and install dev dependencies
Not the required services. I just installed those. Languages and libraries.
fork & clone repo
Since I hope to contribute bug fixes someday, I’ll fork the repo rather than just clone it. I clone my fork instead.
Dev language is weird.
$ git clone firstname.lastname@example.org:brianwisti/mastodon.git $ cd mastodon
.ruby-version file specifies Ruby 2.6.6. Rbenv immediately
warns me that I lack the correct installed version. It also doesn’t recognize
the version when I try installing it, so I must refresh ruby-build
$ git -c ~/.rbenv/plugins/ruby-build pull $ rbenv install
2.6.6 is a bit more specific than “2.5+” but no big deal. Got the right Ruby version. Time to install the gems.
$ bundle install
Oh hey what’s this? It seems relevant to my interests.
⋮ Post-install message from microformats: Prior to version 4.0.0, the microformats gem was named "microformats2."
Adding a task to look more closely at [mircroformats-ruby]. It’s more active than mf2py.
Yarn manages the node-specific project dependencies. Better install that.
$ npm install -g yarn
Okay now I can install the Node stuff.
$ yarn install yarn install v1.22.4 [1/6] Validating package.json... error @tootsuite/mastodon@: The engine "node" is incompatible with this module. Expected version ">=10.13 <13". Got "13.11.0" error Found incompatible module. info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
At some point I should enable automatic
nvm use. Meanwhile I’ll just
$ nvm install Found '/home/random/Projects/mastodon/.nvmrc' with version <12> Downloading and installing node v12.16.3... ⋮ Now using node v12.16.3 (npm v6.14.4) $ npm install -g yarn $ yarn install
No complaints about Node.js versions now. Good. Time to actually set up the application?
Dev docs say
rails db:setup, so that’s what I type.
$ rails db:setup zsh: command not found: rails
Oh right. Because I’m not using a fresh Rails app, but an existing project. I
bundle exec but for some reason I feel stubborn. I must make at
least one step of my installation process match the documentation.
I use direnv, so I can add the path locally.
Then I need to let direnv know this change is acceptable.
$ direnv allow
There’s probably a better Rails-specific or Zsh-specific approach, but I’m in a hurry.
$ rails db:setup
Loads of text follows. That’s good, right?
Instructions go straight to running the application, but that’s not my style.
Getting tests to pass
I want to run tests first. Blame Perl. I have certain expectations
after years of watching
cpan run tests before declaring something installed.
Mhm. That’s what I thought. I’m going to need to write a post about getting this to work, aren’t I?
Let’s skip the hour or two of flailing and digging into past
test: <<: *default # CircleCI precompiles packs prior to running the tests. # Also avoids race conditions in parallel_tests. compile: false # Compile test packs to a separate directory public_output_path: packs-test
true and everything passes. Except they need that as
false for CircleCI. That — does this mean they never run any tests locally
in development? That tests only run after a commit is pushed?
Inconceivable. The very thought is like fingernails on a chalkboard. Surely I missed something in the documentation.
Well I’m going to run tests locally one way or another.
Gimme a second.
Okay how about this?
First, clean up the compiled assets from my config experiment.
$ RAILS_ENV=test rake assets:clobber
Next, precompile the assets and run tests again.
$ RAILS_ENV=test rake assets:precompile $ rspec ⋮ Finished in 4 minutes 10.6 seconds (files took 6.04 seconds to load) 2680 examples, 0 failures, 23 pending
Huzzah! Aside from that ghastly test time. I’ve seen worse. I’ve written worse.
Clearly I need to automate this. Maybe something to do with Foreman. Maybe just a shell script that clobbers, precompiles, and runs tests.
A real fix — if one is needed, and I didn’t just miss a vital paragraph of documentation — would be to give CircleCI its own environment distinct from the default test environment.
Will I actually do anything with my
glitch-soc fork? No idea. But I want to
share this for other dusty Ruby folks whose Rails applications predate
I should at least fiddle with instance settings enough to get a cute screenshot.