This project is built on top of the Abtion Rails Template.
Description of the project. What is it solving? Who are the users?
This section should include any business related explanation that helps understand the context of the project. It could be an excellent idea to include a dictionary of terms, a color legend or a user roles explanation.
- App: staging | production
- Heroku: staging | production
- Asana:
- URL to Abtion's own related git repositories (frontend / backend / admin area / microservices)
- Harvest:
- CI:
- Client name, and if possible, contact details.
- 1Password:
- Error Tracking:
- Activity Monitoring:
- Logging:
- Email Service:
- Client: IT person contact details
If the project is using some special external services (NemID, oAuth, Customer API, etc.) give a short description here. Example: The app is using NemID to authenticate all its users.
- Docker
- ASDF (plugins defined in .tool-versions)
We use dotenv for configuring env vars.
Git hooks defined in install-hooks
bin/install-hooks
The recommended way to run the project is to use docker compose
for databases and asdf
for installing runtimes.\
For running the project locally:
-
In one terminal window:
docker compose up
-
In another terminal window:
asdf install # To install runtimes bin/setup # To install dependencies and initialize the database bin/rails s # To run the webserver
-
The project can now be accessed at http://localhost:3000
It is also possible to run everything locally, but it requires locally setting up the services specified in the docker-compose.yml.
It will also require changes to the connection string env vars.
Checkout the bin for scripts and binstubs
package.json also contains a few frontend specific scripts
Commonly used:
bundle install # Install ruby gems
npm install # Install frontend dependencies
bin/rspec # Run rails tests
npm run test # Run frontend tests
bin/lint # Run all linters
bin/lint-fix # Run all linters and attempt to fix problems
bin/test-all-strict # Run all tests and linters
bin/shakapacker-dev-server # Watch for frontend changes and compile on the go
Spring is also available for development. Since using spring can cause hard-to-debug errors, the binstubs are not springifie, but you can run easily use spring with bin/spring [command]
, e.g.:
bin/spring rspec
bin/spring rails s
Inclusions:
- Devise for authentication
- Pundit for authorization
- Shakapacker
- Jest
- Rollbar error monitoring
- Prettier for linting javascript files
- RSpec
- FactoryBot
- Capybara for system specs
- Rubocop for linting ruby files
- Sidekiq for running jobs
- Spring (without binstubs)
Exclusions:
- Turbolinks
user: admin@example.com
password: password
When system spec fails in CI a screenshot will be saved as a Github Actions artifact. If need be you can download the capybara.zip
file and extract it to get to the screenshots.
Sidekiq
provides useful web-interface (available at /sidekiq).
For staging/production envs, username and password are set with - and can be found in - env vars SIDEKIQ_USERNAME
and SIDEKIQ_PASSWORD
for the respective envs.
Commits to main
are automatically deployed to the staging environment (after they've passed CI).
Deployments to production happen by promoting the staging environment.
- Description:
- Auth: Where can it be found. E.g. .env file
- Documentation:
- Web interface:
- IT Contact person: