You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 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
  • 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.  
    • Rails app
  • CircleCI
  • 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 
  • No labels