An admin dashboard for the Identity project.
These instructions assume identity-idp is also running locally at http://localhost:3000. This dashboard is configured to run on http://localhost:3001.
- Make sure Postgres is running. For example, on macOS:
$ brew services start postgres
- Set up the environment with:
$ make setup
- And run the app server:
$ make run
In the development environment, an administrator user account is created during the setup process with the email address [email protected] . If this is the first time you've run the application, you will want to log in with this email address, or create an account if one doesn't already exist. After you've logged in as the administrator, you can add new users and teams.
Alternatively, log in using any account, then promote the user to an admin using the users:make_admin Rake task:
bundle exec rake users:make_admin [email protected],First,Last
Run RSpec tests using:
$ make test
Branches should be specifically named in a standard format that closely matches the current style of [TICKET-NUMBER]-feature-name/user-ticket-what-the-branch-does This will group the branches of the feature together, and easily identified
Branches should be specific to a specific feature. Sub-branches can be created for larger features that require development broken into multiple parts for completion.
Branches should be rebased to main to keep the history on the main branch clear and easy to follow.
Branches should be completed and sent for review via Pull Request and merged into main via squashed merge-commit to keep noise in main down.
How do we conduct code review What are norms we want to enforce
For code reviewers Borrowed from 18F code review standards
- Understand why the code is necessary (bug, user experience, refactoring)
- Seek to understand the author's perspective.
- Clearly communicate which ideas you feel strongly about and those you don't.
- Identify ways to simplify the code while still solving the problem.
- Offer alternative implementations, but assume the author already considered them. ("What do you think about such-and-such here?")
- Sign off on the pull request with a 👍 or "Ready to merge" comment.
- Wait to merge the branch until it has passed Continuous Integration testing.
- Use Conventional Comments in order to clarify whether a comment is blocking or non-blocking for merging the PR.
When do we use feature tests / integration / regression / unit tests
We primarily write tests in rpsec using additional tools like capybara for feature tests.
To check test coverage with RSPEC:
COVERAGE=true bundle exec rspec {my_spec_file}
Note that when running this command your coverage file will show that all other files don't have coverage.
-
Ruby using Rubocop rules. These rules are currently under active development.
-
JavaScript using ESLint. We use the ESLint plugin from IdP as well as some rules to ensure we don't error on upstream dependencies that use variant linting rules or minified compiled assets.
- YARD docs to ensure they have no warnings and also we enforce that the
LogEventsclass has YARD documentation for all its methods
You can see the YARD docs for yourself by running bin/yard and then opening [doc/yard/index.html] in a browser. Doing so should show you this README with links to documented classes. Currently, we aren't including YARD doc generation in our build process and then committing them, though this may change later.
The project is in the public domain, and all contributions will also be released in the public domain. By submitting a pull request, you are agreeing to waive all rights to your contribution under the terms of the CC0 Public Domain Dedication.
This project constitutes an original work of the United States Government.