- Install VirtualBox (
sudo apt-get install virtualbox
) - Install the latest version of Vagrant (
sudo apt-get install vagrant
) cd hkn-rails
vagrant up
If Vagrant gives you an error along the lines of The guest machine entered an invalid state...
, try to start the VM from VirtualBox. If VirtualBox
gives you the error VT-x is not available...
, do the following:
1. `vagrant halt`
2. `vagrant destroy`
3. Change your BIOS settings to enable VM virtualization (this will
require a system reboot)
4. `vagrant up` and continue to step 6.
vagrant ssh
cd /vagrant
bundle exec rails s -b 0
- On your host machine, visit
localhost:3000
This setup uses a Debian 9 (stretch) virtual machine, running on VirtualBox and managed with Vagrant (dependencies, database setup, etc).
Your copy of hkn-rails on your host is a shared directory with \vagrant
on
your guest, so you can edit files in either machine.
The guest is configured to port forward 3000 on the vm to 3000 on the host.
When creating virtual machine, the provisioning script in Vagrantfile
will:
- Install Debian dependencies with
apt-get
:build-essentials
,vim
,git
,mariadb
, etc. - Create a MySQL user
hkn_rails
, with passwordhkn_rails
, with all privileges on all databaseshkn_rails_*
. - Install RVM, a Ruby version manager, so we can install the specific version of Ruby that matches the production server.
- Compile and install Ruby.
- Install Bundler, a Ruby environment manager, with the Ruby package manager gem.
- Install Ruby dependencies with
bundle
. - Create
config/database.yml
andconfig/secrets.yml
from the sample files inconfig/
. - Create the MySQL database:
bundle exec rake db:setup
.
- Start the VM with
vagrant up
. It must boot, like any operating system. - Stop the VM with
vagrant halt
orvagrant suspend
. - Re-run the provision script with
vagrant up --provision
.
You need to run these operations inside /vagrant
. If you run these
directly after ssh-ing into the VM, you will be in the home folder
/home/vagrant
, and your operations will fail.
- (Re)install all Ruby dependencies with
bundle install
. - Run all Ruby operations with
bundle exec <command here>
. This ensures you have access to thebundle
-installed dependencies. - You may occasionally need to run with a particular rails environment:
RAILS_ENV=production bundle exec <command here>
. Besidesproduction
, there is alsodevelopment
(the default) andtest
(rarely used). - Run the Rails web server with
bundle exec rails server -b 0.0.0.0
. - Run the Rails console with
bundle exec rails console
. - Setup the database with
bundle exec rake db:setup
. - Reset the database (drop & setup) with
bundle exec rake db:reset
. - List all
rake
tasks withbundle exec rake --tasks
.
If you would like to run with real data from the production database, then:
- Download a backup of the website from compserv. These are kept secret because they contain sensitive data like password hashes.
- Move the database backup into your copy of hkn-rails.
- Make sure the database has been rsync'd into your VM (either by
vagrant rsync
or byvagrant rsync-auto
). rake db:backup:restore FROM=[path_to_backup]
See section below on making backups for more info on getting a backup.
First, ensure that your dev environment is setup:
bundle install
Then deploy to the production
target with:
bundle exec cap production deploy
Once you've ssh'd into the OCF apphost server (hkn@apphost.ocf.berkeley.edu
),
activate the .rvm
environment
. ~/.rvm/scripts/rvm
Nothing will show up (including the "(conda)" or "(.venv)" that you are used to), but the following console commands should now work (Solves problem with: "Your Ruby version is #.#.#, but your Gemfile specified #.#.#" when trying to run a Rails console)
Then, cd into the current production deploy folder and run:
bundle exec rails console -e production
This will open a Ruby interactive shell with access to the database model.
If you would like to sandbox your session (roll back all changes once you finish), run:
bundle exec rails console -e production --sandbox
- On apphost.ocf.berkeley.edu, go into
~/hkn-rails/prod/current/
RAILS_ENV=production bundle exec rake db:backup:dump
(actual script is inhkn-rails/lib/tasks/backups.rb
)
This makes a backup in hkn-rails/db/backups
, name based on datetime by
default.
To load a backup:
rake db:reset && rake db:backup:restore FROM=[path]
The course survey uploads do need to be manually re-uploaded sometimes, especially if a column is missing. (Note that this is a bug! By no means is this expected behavior, nor should it be allowed to continue.)
scp
the relevant course survey CSV to apphost.ocf.berkeley.edu.ssh
in and go into~/hkn-rails/prod/current/
.- Execute the following rake task to import surveys:
$ RAILS_ENV=production bundle exec rake "coursesurveys:import[<semester>, <ta?>, <commit?>]"
FROM=survey.csv
If specific columns of data are missing, specify which columns to upload
(by SurveyAnswer
model IDs, requires Rails console access) with
the COLS
environment variable:
$ RAILS_ENV=production bundle exec rake "coursesurveys:import[<semester>,<ta?>,<commit?>]"
FROM=survey.csv COLS=id1,id2,...
Example: to upload the instructor data for Fall 2019 (saving to the database), only uploading the ID=1 survey question ('effectiveness'), we run:
$ RAILS_ENV=production bundle exec rake "coursesurveys:import[Fall 2019,false,true]"
FROM=survey.csv COLS=1
Example: to upload all TA data for Summer 2019 (without saving to the database), we run:
$ RAILS_ENV=production bundle exec rake "coursesurveys:import[Summer 2019,true,false]"
FROM=survey.csv
To serve new static files in production, first run
RAILS_ENV=production bundle exec rake assets:precompile
bundle install
- Add searchables to your model
- Reindex
Sunspot includes its own version of solr that's easy to use, and you don't have to install Solr on Tomcat/Jetty/etc. yourself.
Note: Puts index files somewhere in your /tmp
-
rake sunspot:solr:start
-
rake sunspot:solr:reindex
whenever you change the 'searchable' information in your model.You don't have to reindex when you change data, that will be reindexed automatically. Make sure the solr server is started before you reindex.
-
rake sunspot:solr:stop
if you want to stop the search daemon
Sunspot:Solr presents an admin page on ports 8981:8983 (per environment; see
config/sunspot.yml
) that you probably want to close to the outside (this is
already done in production):
iptables -I INPUT -j ACCEPT --dport 8981:8983 -i lo # Allow local only
iptables -I INPUT -j DROP --dport 8981:8983 # Else, drop
For examples of searching, see coursesurveys#search and course.rb.
To generate the API documentation, run:
bundle exec yard
This will generate documentation from source comments at doc/
.