You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 10
Next »
- Main GitHub repo for Cornell
- Main underlying Spotlight repo
- Installation from scratch on local machine
- Generic Spotlight
- To run Exhibits code from machine
- Look at https://github.com/cul-it/exhibits-library-cornell-edu/blob/dev/README.md
- Steps I took on my local machine to build
- mkdir cornellexhibittest
- cd cornellexhibittest
- git clone git@github.com:cul-it/exhibits-library-cornell-edu.git .
- (I used RVM so had to ensure the right version of Ruby was being employed. "rvm use 2.7.3")
- bundle install
- bin/rake db:migrate
- cp .env.example .env
- Look through the .env file and follow the instructions for setting up the database (under the #mysql section) and setting up the database name, username, and password
- For Solr URL, you can try the Solr wrapper method. I also set up a separate Solr index using the schema files I saw being used and then set Solr _URL to point to my local Solr URL
- Update SITE_ADMINS to include the site admin user email addresses you want to use
- Generate a Devise secret key as the instructions tell you
- "rails server" to start the system
- Go to sign up and enter the email you already added to the site admins and create a password. When you login, you should be able to see the "Site Administration" link under your email address.
- Deployment and Release/updating process
- https://github.com/cul-it/exhibits-library-cornell-edu/wiki/Release-Process although portions may be out of date.
- Updating dev will kick off CircleCI (see below - you should have logged in to CircleCI already for this to take effect, it appears). If you want to see any console output and/or what may not be passing, you can check CircleCI logs . You can also run rubocop directly on the code by going to the top level directory and running bin/rubocop and see the resulting messages.
- To actually build from a branch onto one of the servers, you must do the following
- Example: Deploying dev to the integration branch.
- Under AWS Jenkins, (https://awsjenkins.library.cornell.edu), you can find "exhibits-staging-1" and "exhibits-prod-1" which deploy to staging and production separately. Production is set to deploy from the main branch and will not let you pick a different branch to deploy.
- Components for the system (also see Components: Servers, Solr index and Rails database)
- Databases
- Please ask Greg for the username and password for the database, as in integration, staging, and production we are using AWS RDS, and the username and passwords are stored in LastPass.
- The databases include various tables for storing user information, but also information about the "resources" which include the exhibits themselves. You can see the schema here https://github.com/cul-it/exhibits-library-cornell-edu/blob/dev/db/schema.rb or login to MySQL and access the database on your local machine to get a sense of which data is stored where.
- Solr index
- There are separate indices used for integration, staging, and production. The Solr index captures the main metadata for the resources (e.g. title, description, copyright, etc.) and the location of the images that are uploaded and to which exhibit these items correspond. (Based on experience with the code, this information isn't published to the Solr index until the exhibit itself has been published. Until that point, it appears the information about exhibits and related images is stored elsewhere. You may wish to confirm.)
- Rails app
- AWS storage for images (unsure so needs confirmation)
- You may wish to confirm but the actual files are possibly being stored in AWS S3.
- CircleCI
- Login to http://circleci.com. You will need to login and connect to the repository before the built-in GitHub CircleCI can kick off and before you can see the output of those CircleCI processes.
- Pick login with GitHub
- Go to Projects
- Pick "exhibits-library-cornell-edu"
- Adding site admin email addresses
- Cornell exhibits has an added layer of permissions for a site wide admin which is defined in the elastic bean stalk configuration.
- Access elastic beanstalk environments through the AWS console. Look for exhibits-integration or exhibits-prod-1.
- Go to configuration → software
- Click edit and go to environment properties
- Edit "SITE_ADMINS" and add the email addresses you like (email addresses are separated by semi-colons)
- Click "Apply" to update the configuration
- After updating the configuration, rebuild environment. (Restarting the app seems insufficient and leaves the site down)
- If you are deploying the system locally, set up a .env file based on https://github.com/cul-it/exhibits-library-cornell-edu/blob/dev/.env.example
- Signing up an external user
- Ask the user to click on "Admin Login" on the bottom of the page and then select "Sign up". This should take them to https://exhibits.library.cornell.edu/users/sign_up
- Once they have signed up, login as administrator into the site. Go to "Manage Users" under Actions. You can change their role in general under this section (e.g. make someone an "admin"). You can also select a particular exhibit, go to "Exhibit Dashboard" in the menu under your email address on the top right of the page, and then "Configuration" in the left column. Click on "Users" under Configuration and you can select "add a new user" to add this user to the list of people who have roles for this specific exhibit.
