<<TKTK: quick summary of project>>
If you're new to Rails, see the Getting Started with Rails guide for an introduction to the framework.
- Install Ruby ruby-3.0.2
- Install NodeJS 14.18
- Install PostgreSQL:
brew install postgresql
- Add postgres to your PATH if it wasn't done automatically
echo 'export PATH="/usr/local/opt/postgresql/bin:$PATH"' >> ~/.zshrc
- Start the server
brew services start postgresql
- Add postgres to your PATH if it wasn't done automatically
- Install Ruby dependencies:
bundle install
- Install chromedriver for integration tests:
brew install --cask chromedriver
- Chromedriver must be allowed to run. You can either do that by:
- The command line:
xattr -d com.apple.quarantine $(which chromedriver)
(this is the only option if you are on Big Sur) - Manually: clicking "allow" when you run the integration tests for the first time and a dialogue opens up
- The command line:
- Chromedriver must be allowed to run. You can either do that by:
- Install JS dependencies:
yarn install
- Create database:
bundle exec rake db:create
- Run migrations:
bundle exec rake db:migrate
- Run the server:
bundle exec rails s
- Visit the site: http://localhost:3000
Environment variables can be set in development using the dotenv gem.
Consistent but sensitive credentials should be added to config/credentials.yml.env
by using $ rails credentials:edit
Any changes to variables in .env
that should not be checked into git should be set
in .env.local
.
If you wish to override a config globally for the test
Rails environment you can set it in .env.test.local
.
However, any config that should be set on other machines should either go into .env
or be explicitely set as part
of the test.
TBD
The system's Content-Security-Policy header prevents <script>
and <style>
tags from working without further
configuration. Use <%= javascript_tag nonce: true %>
for inline javascript.
See the CSP compliant script tag helpers ADR for more information on setting these up successfully.
- Tests:
bundle exec rake spec
- Accessbility scan:
./bin/pa11y-scan
- Dynamic security scan:
./bin/owasp-scan
- Ruby static security scan:
bundle exec rake brakeman
- Ruby dependency checks:
bundle exec rake bundler:audit
- JS dependency checks:
bundle exec rake yarn:audit
Run everything: bundle exec rake
GitHub actions are used to run all tests and scans as part of pull requests.
Security scans are also run on a scheduled basis. Weekly for static code scans, and daily for dependency scans.
Each environment has dependencies on a PostgreSQL RDS instance managed by cloud.gov. See cloud.gov docs for information on RDS.
First time only: create DB service with cf create-service aws-rds micro-psql resource_search-rds-stage
cf push --strategy rolling --vars-file config/deployment/stage.yml --var rails_master_key=$(cat config/master.key)
First time only: create DB service with cf create-service aws-rds <<SERVICE_PLAN_NAME>> resource_search-rds-prod
cf push --strategy rolling --vars-file config/deployment/prod.yml --var rails_master_key=$(cat config/master.key)
All configuration that needs to be added to the deployed application's ENV should be added to
the env:
block in manifest.yml
Items that are both public and consistent across staging and production can be set directly there.
Otherwise, they are set as a ((variable))
within manifest.yml
and the variable is defined depending on sensitivity:
- Store variables that must be secret using GitHub Environment Secrets
- Add the secret to the
env:
block of the deploy action as in this example - Add the appropriate
--var
addition to thepush_arguments
line on the deploy action as in this example
Configuration that changes from staging to production, but is public, should be added to config/deployment/stage.yml
and config/deployment/prod.yml
Architectural Decision Records (ADR) are stored in doc/adr
To create a new ADR, first install ADR-tools if you don't
already have it installed.
brew install adr-tools
Then create the ADR:
adr new Title Of Architectural Decision
This will create a new, numbered ADR in the doc/adr
directory.
This will continue to evolve as the project moves forward.
- Pull down the most recent main before checking out a branch
- Write your code
- If a big architectural decision was made, add an ADR
- Submit a PR
- If you added functionality, please add tests.
- All tests must pass!
- Ping the other engineers for a review.
- At least one approving review is required for merge.
- Rebase against main before merge to ensure your code is up-to-date!
- Merge after review.
- Squash commits into meaningful chunks of work and ensure that your commit messages convey meaning.
TBD