Merge pull request #826 from GSA/update-e2e-info

Add E2E configuration information to docs
This commit is contained in:
Carlo Costino
2024-03-04 15:39:11 -05:00
committed by GitHub
2 changed files with 63 additions and 0 deletions

View File

@@ -299,6 +299,36 @@ brew services start postgresql@15
brew services start redis
```
### Final environment setup
There's one final thing to adjust in the newly created `.env` file. This
project has support for end-to-end (E2E) tests and has some additional checks
for the presence of an E2E test user so that it can be authenticated properly.
In the `.env` file, you should see this section:
```
#############################################################
# E2E Testing
NOTIFY_E2E_TEST_EMAIL=example@fake.gov
NOTIFY_E2E_TEST_PASSWORD="don't write secrets to the sample file"
```
You can leave the email address alone or change it to something else to your
liking.
**You should absolutely change the `NOTIFY_E2E_TEST_PASSWORD` environment
variable to something else, preferably a lengthy passphrase.**
With those two environment variable set, the database migrations will run
properly and an E2E test user will be ready to go for use in the admin project.
_Note: Whatever you set these two environment variables to, you'll need to
match their values on the admin side. Please see the admin README and
documentation for more details._
## Running the Project and Routine Maintenance
The first time you run the project you'll need to run the project setup from the
@@ -410,6 +440,7 @@ instructions above for more details.
- [CI testing](./docs/all.md#ci-testing)
- [Manual testing](./docs/all.md#manual-testing)
- [To run a local OWASP scan](./docs/all.md#to-run-a-local-owasp-scan)
- [End-to-end testing](./docs/all.md#end-to-end-testing)
- [Deploying](./docs/all.md#deploying)
- [Egress Proxy](./docs/all.md#egress-proxy)
- [Managing environment variables](./docs/all.md#managing-environment-variables)

View File

@@ -11,6 +11,7 @@
- [CI testing](#ci-testing)
- [Manual testing](#manual-testing)
- [To run a local OWASP scan](#to-run-a-local-owasp-scan)
- [End-to-end testing](#end-to-end-testing)
- [Deploying](#deploying)
- [Egress Proxy](#egress-proxy)
- [Managing environment variables](#managing-environment-variables)
@@ -307,6 +308,37 @@ The equivalent command if you are running the API locally:
docker run -v $(pwd):/zap/wrk/:rw -t owasp/zap2docker-weekly zap-api-scan.py -t http://host.docker.internal:6011/docs/openapi.yml -f openapi -c zap.conf -r report.html
```
## End-to-end Testing
In order to run end-to-end (E2E) tests, which are managed and handled in the
admin project, a bit of extra configuration needs to be accounted for here on
the API side as well. These instructions are in the README as they are
necessary for project setup, and they're copied here for reference.
In the `.env` file, you should see this section:
```
#############################################################
# E2E Testing
NOTIFY_E2E_TEST_EMAIL=example@fake.gov
NOTIFY_E2E_TEST_PASSWORD="don't write secrets to the sample file"
```
You can leave the email address alone or change it to something else to your
liking.
**You should absolutely change the `NOTIFY_E2E_TEST_PASSWORD` environment
variable to something else, preferably a lengthy passphrase.**
With those two environment variable set, the database migrations will run
properly and an E2E test user will be ready to go for use in the admin project.
_Note: Whatever you set these two environment variables to, you'll need to
match their values on the admin side. Please see the admin README and
documentation for more details._
# Deploying
The API has 3 deployment environments, all of which deploy to cloud.gov: