mirror of
https://github.com/GSA/notifications-api.git
synced 2026-08-01 04:08:50 -04:00
merge from main
This commit is contained in:
@@ -3,7 +3,7 @@
|
||||
|
||||
| CREATED DATE | LAST UPDATED | STATUS | AUTHOR | STAKEHOLDERS |
|
||||
| :---: | :---: | :---: | :---: | :---: |
|
||||
| 06/06/2023 | 06/15/2023 | Proposed | @ccostino | @GSA/notify-contributors |
|
||||
| 06/06/2023 | 09/15/2023 | Accepted | @ccostino | @GSA/notify-contributors |
|
||||
|
||||
|
||||
## CONTEXT AND PROBLEM STATEMENT
|
||||
@@ -48,8 +48,7 @@ that are already in place, which prevent the following:
|
||||
|
||||
## CONSIDERED OPTIONS
|
||||
|
||||
These are the different approaches we're considering for implementing this
|
||||
change:
|
||||
This is the approach we've considered for implementing this change:
|
||||
|
||||
- **Adjust `InvitedUser` management in the API:** Instead of deleting
|
||||
`InvitedUser` objects, we manage them instead and track their `created_at`
|
||||
@@ -108,8 +107,6 @@ value for the effort.
|
||||
|
||||
## VALIDATION AND NEXT STEPS
|
||||
|
||||
TBD, pending additional ideas and discussion!
|
||||
|
||||
Once a decision is made though, a seperate issue should be written up for the
|
||||
API changes that need to take place, and then follow-on work will be needed on
|
||||
the admin side in https://github.com/GSA/notifications-admin/issues/96 to make
|
||||
|
||||
36
docs/adrs/0006-use-for-dependency-management.md
Normal file
36
docs/adrs/0006-use-for-dependency-management.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# Use `poetry` for dependency management
|
||||
|
||||
Date: 2023-09-08
|
||||
|
||||
### Status
|
||||
|
||||
Accepted
|
||||
|
||||
### Context
|
||||
|
||||
Our initial decision to use was primarily driven by [built-in support in Cloud Foundry](https://docs.cloudfoundry.org/buildpacks/python/index.html#pipenv). In practice, we have found that we still need to export the requirements file as part of the build process, removing the benefit.
|
||||
|
||||
Meanwhile, `poetry` appears to be the informal standard around TTS. It's relatively simple for a dev to switch between them, but we do value consistency across the organization.
|
||||
|
||||
### Decision
|
||||
|
||||
Let's use `poetry`.
|
||||
|
||||
### Consequences
|
||||
|
||||
We expect this to be a one-time cost.
|
||||
|
||||
### Author
|
||||
|
||||
@stvnrlly
|
||||
|
||||
|
||||
### Next Steps
|
||||
|
||||
We will need to:
|
||||
|
||||
- Convert to `poetry`
|
||||
- Convert our CI/CD processes
|
||||
- Ensure [proper Dependabot configuration](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file)
|
||||
- Update developer documentation
|
||||
- Get familiar with the tool
|
||||
@@ -38,9 +38,8 @@ whether or not to move forward, with or without any changes.
|
||||
|
||||
## How are ADRs created, reviewed, and maintained?
|
||||
|
||||
First, we have an ADR template that folks can use to work off of. The template
|
||||
exists as both a GitHub issue template and a standalone Markdown file that can
|
||||
be copied as needed if folks prefer to work locally first.
|
||||
First, we have an ADR issue template that folks can use to start. Select the
|
||||
"Create a new ADR" option when creating a new issue.
|
||||
|
||||
By following the template, we ensure that our ADRs are consistent in language
|
||||
and structure. This allows us to easily review the documentions and discuss
|
||||
@@ -82,14 +81,22 @@ be links or the link will go to a :lock: *private document* instead.
|
||||
|
||||
To create a new ADR in this repository, you can do one of two things:
|
||||
|
||||
- Open a new GitHub issue and select the Architecture Decision Record issue type
|
||||
- Open a new GitHub issue and select the "Create a new ADR" option
|
||||
- Clone the repo locally, create a new branch for yourself, and make a copy of
|
||||
the Markdown template
|
||||
|
||||
In either scenario, check to see what the latest ADR filename is, because they
|
||||
always start with a number (e.g., `0001`). Name your ADR with a number one
|
||||
after the last ADR written; if the latest ADR starts with `0021-`, your ADR
|
||||
should start with `0022-`.
|
||||
Creating an ADR manually should be used primarily when memorializing a decision
|
||||
that the team has already made. Anything requiring discussion should be created
|
||||
as an issue.
|
||||
|
||||
We are using [some automation]([url](https://github.com/18F/adr-automation/))
|
||||
to turn proposed-ADR issues into accepted-ADR documents. When an ADR is accepted,
|
||||
apply the `ADR: accepted` label and close the issue. The action will open a pull
|
||||
request with the document, which can then be merged.
|
||||
|
||||
When working locally, be sure to number your ADR based on the last ADR written;
|
||||
if the latest ADR starts with `0021-`, for example, your ADR should start with
|
||||
`0022-`.
|
||||
|
||||
At this point, it is a matter of filling in the details outlined in the template
|
||||
that are relevant to the ADR.
|
||||
@@ -100,7 +107,8 @@ that are relevant to the ADR.
|
||||
Once an ADR is created, it's time for review and discussion! This could happen
|
||||
a few ways:
|
||||
|
||||
- Asynchronously via comments on the pull request itself
|
||||
- Asynchronously via comments on the issue itself
|
||||
- Synchronously-ish on Slack
|
||||
- Synchronously with a scheduled meeting(s) and a facilitator
|
||||
- A combination of these, depending on the nature of the ADR and needs of the
|
||||
team
|
||||
@@ -172,8 +180,9 @@ top!).
|
||||
|
||||
| ADR | TITLE | CURRENT STATUS | IMPLEMENTED | LAST MODIFIED |
|
||||
| :---: | :---: | :---: | :---: | :---: |
|
||||
| [ADR-0006](./0006-use-for-dependency-management.md) | [Use `poetry` for Dependency Management](./0006-use-for-dependency-management.md) | Accepted | Yes | 09/08/2023 |
|
||||
| [ADR-0005](./0005-agreement-data-model.md) | [Agreement info in data model](./0005-agreement-data-model.md) | Accepted | No | 07/05/2023 |
|
||||
| [ADR-0004](./0004-designing-pilot-content-visibility.md) | [Designing Pilot Content Visibility](./0004-designing-pilot-content-visibility.md) | Proposed | No | 06/20/2023 |
|
||||
| [ADR-0003](./0003-implementing-invite-expirations.md) | [Implementing User Invite Expirations](./0003-implementing-invite-expirations.md) | Proposed | No | 06/15/2023 |
|
||||
| [ADR-0003](./0003-implementing-invite-expirations.md) | [Implementing User Invite Expirations](./0003-implementing-invite-expirations.md) | Accepted | No | 09/15/2023 |
|
||||
| [ADR-0002](./0002-how-to-handle-timezones.md) | [Determine How to Handle Timezones in US Notify](./0002-how-to-handle-timezones.md) | Accepted | Yes | 06/15/2023 |
|
||||
| [ADR-0001](./0001-establishing-adrs-for-us-notify.md) | [Establishing ADRs for US Notify](./0001-establishing-adrs-for-us-notify.md) | Accepted | Yes | 06/15/2023 |
|
||||
|
||||
16
docs/all.md
16
docs/all.md
@@ -182,7 +182,7 @@ TODO: create env vars for these origin and destination email addresses for the r
|
||||
|
||||
#### Move SNS out of sandbox.
|
||||
|
||||
This should be complete for all regions U.S. Notify has been deployed to or is currently planned to be deployed to.
|
||||
This should be complete for all regions Notify.gov has been deployed to or is currently planned to be deployed to.
|
||||
|
||||
1. Visit the SNS console for the region you will be sending from. Notes:
|
||||
1. SNS settings are per-region, so each environment must have its own region
|
||||
@@ -247,7 +247,7 @@ Within GitHub Actions, several scans take place every day to ensure security and
|
||||
|
||||
If you're checking out the system locally, you may want to create a user quickly.
|
||||
|
||||
`pipenv run flask command create-test-user`
|
||||
`poetry run flask command create-test-user`
|
||||
|
||||
This will run an interactive prompt to create a user, and then mark that user as active. *Use a real mobile number* if you want to log in, as the SMS auth code will be sent here.
|
||||
|
||||
@@ -327,8 +327,8 @@ Rules for use:
|
||||
$ terraform plan
|
||||
$ terraform apply
|
||||
```
|
||||
1. start a pipenv shell as a shortcut to load `.env` file variables: `$ pipenv shell`
|
||||
1. Output requirements.txt file: `pipenv requirements > requirements.txt`
|
||||
1. start a poetry shell as a shortcut to load `.env` file variables: `$ poetry shell`
|
||||
1. Output requirements.txt file: `poetry export --without-hashes --format=requirements.txt > requirements.txt`
|
||||
1. Deploy the application:
|
||||
```
|
||||
cf push --vars-file deploy-config/sandbox.yml --var NEW_RELIC_LICENSE_KEY=$NEW_RELIC_LICENSE_KEY
|
||||
@@ -405,7 +405,7 @@ command Using a command allows the operation to be tested, both with `pytest` an
|
||||
|
||||
To see information about available commands, you can get a list with:
|
||||
|
||||
`pipenv run flask command`
|
||||
`poetry run flask command`
|
||||
|
||||
Appending `--help` to any command will give you more information about parameters.
|
||||
|
||||
@@ -681,7 +681,7 @@ For further details of the system and how it connects to supporting services, se
|
||||
Run Book
|
||||
========
|
||||
|
||||
Policies and Procedures needed before and during US Notify Operations. Many of these policies are taken from the U.S. Notify System Security & Privacy Plan (SSPP).
|
||||
Policies and Procedures needed before and during US Notify Operations. Many of these policies are taken from the Notify.gov System Security & Privacy Plan (SSPP).
|
||||
|
||||
Any changes to policies and procedures defined both here and in the SSPP must be kept in sync, and should be done collaboratively with the System ISSO and ISSM to ensure
|
||||
that the security of the system is maintained.
|
||||
@@ -795,9 +795,9 @@ US_Notify Administrators are responsible for ensuring that remediations for vuln
|
||||
|
||||
## <a name="dns"></a> DNS Changes
|
||||
|
||||
U.S. Notify DNS records are maintained within [the 18f/dns repository](https://github.com/18F/dns/blob/main/terraform/notify.gov.tf). To create new DNS records for notify.gov or any subdomains:
|
||||
Notify.gov DNS records are maintained within [the 18f/dns repository](https://github.com/18F/dns/blob/main/terraform/notify.gov.tf). To create new DNS records for notify.gov or any subdomains:
|
||||
|
||||
1. Update the `notify.gov.tf` terraform to update or create the new records within Route53 and push the branch to the 18f/dns repository.
|
||||
1. Update the `notify.gov.tf` terraform to update oƒr create the new records within Route53 and push the branch to the 18f/dns repository.
|
||||
1. Open a PR.
|
||||
1. Verify that the plan output within circleci creates the records that you expect.
|
||||
1. Request a PR review from the 18F/tts-tech-portfolio team
|
||||
|
||||
Reference in New Issue
Block a user