<
If you're new to Rails, see the Getting Started with Rails guide for an introduction to the framework.
brew install postgresql
echo 'export PATH="/usr/local/opt/postgresql/bin:$PATH"' >> ~/.zshrc
brew services start postgresql
bundle install
brew install --cask chromedriver
xattr -d com.apple.quarantine $(which chromedriver)
(this is the only option if you are on Big Sur)yarn install
bundle exec rake db:create
bundle exec rake db:migrate
bundle exec rails s
You can set up a local UAA server. Instructions modified from this cloud.gov repo
Install docker if you haven't already
mkdir /tmp/uaa
cp local_uaa_server.yml /tmp/uaa/uaa.yml
docker run -d --name uaa-uaa -p 8080:8080 -v /tmp/uaa:/uaa:rw hortonworks/cloudbreak-uaa:3.6.3
Username: user1 Password: wombat
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 explicitly set as part
of the test.
TBD
<script>
and <style>
securityThe 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.
bundle exec rake spec
bundle exec rake standard
./bin/pa11y-scan
./bin/owasp-scan
bundle exec rake brakeman
bundle exec rake bundler:audit
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:
Make sure the application is open to public and trusted local network egress so it can connect to the DB and UAA server
cf bind-security-group public_networks_egress sandbox-gsa --space davida.marion
cf bind-security-group trusted_local_networks_egress sandbox-gsa --space davida.marion
cf create-service aws-rds micro-psql project_resource_search-rds-stage
cf create-service cloud-gov-identity-provider oauth-client uaa-client
cf create-service-key \
uaa-client \
uaa-service-key \
-c '{"redirect_uri": ["https://project_resource_search-stage.app.cloud.gov/auth", "https://project_resource_search-stage.app.cloud.gov/logout"]}'
cf service-key uaa-client uaa-service-key
Take the output and open the Rails credentials:
EDITOR="vim" rails credentials:edit
Copy the client id and client secret into your credentials using the keys:
uaa_client_id: $CLIENT_ID_HERE
uaa_client_secret: $CLIENT_SECRET_HERE
To deploy:
cf push --strategy rolling --vars-file config/deployment/stage.yml --var rails_master_key=$(cat config/master.key)
Once the deploy has finished, you have to run migrations.
To do this, ssh into the instance of the resource search, configure your session to match your application's environment and then run the migrations.
cf ssh project_resource_search-stage
/tmp/lifecycle/shell
rake db:migrate
TODO: make the deployment steps into a script
First time only: create DB service with cf create-service aws-rds <<SERVICE_PLAN_NAME>> project_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:
env:
block of the deploy action as in this example--var
addition to the push_arguments
line on the deploy action as in this exampleConfiguration 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.
TBD