Update prime-router docs to reference main branch (#16497)

* update prime-router doc references from master to main

.environment/chatops/help.txt

@@ -3,7 +3,7 @@ ACTION
 USAGE
     [<@bot>] gh-deploy [<branch>] to [<branch>] [OPTIONAL: for <owner/repo>]
 EXAMPLES
-    @DevBot gh-deploy master to trialfrontend1
+    @DevBot gh-deploy main to trialfrontend1
 ==========================================================================
 ACTION
     Lock branch to prevent deployments
@@ -26,4 +26,4 @@ USAGE
     [<@bot>] gh-run [<workflow file>] [OPTIONAL: <owner/repo> <branch>] [OPTIONAL: --inputs <a:b,c:d>] 
 EXAMPLES
     @DevBot gh-run destroy_demo_environment.yml --inputs env_name:demo1
-    @DevBot gh-run destroy_demo_environment.yml CDCgov/prime-reportstream master --inputs env_name:demo1
+    @DevBot gh-run destroy_demo_environment.yml CDCgov/prime-reportstream main --inputs env_name:demo1

CONTRIBUTING.md

@@ -69,7 +69,7 @@ Once your changes and tests are ready to submit for review:
 
 2. **Rebase your changes**
 
-    Update your local repository with the most recent code from the principal repository, and rebase your branch on top of the latest master branch. We prefer your initial changes to be squashed into a single commit. Later, if we ask you to make changes, add the changes as separate commits.  This makes the changes easier to review.  
+    Update your local repository with the most recent code from the principal repository, and rebase your branch on top of the latest main branch. We prefer your initial changes to be squashed into a single commit. Later, if we ask you to make changes, add the changes as separate commits.  This makes the changes easier to review.  
 
 3. **Submit a pull request**
 

DEPLOYMENTS.md

@@ -2,16 +2,16 @@
 
 ReportStream production deployments take place on Tuesdays and Thursday around 10am EST.
 
-The testing and staging environments are automatically deployed on every merge into `master` through our Continuous Deployment pipeline.
+The testing and staging environments are automatically deployed on every merge into `main` through our Continuous Deployment pipeline.
 
 ## How is ReportStream deployed?
 
 We automatically deploy changes through [GitHub Actions](.github/workflows/release.yml) based on changes in target branches as described in the table below. These changes can only enter these branches through successfully reviewed Pull Requests.
 
 | Changes are merged into branch | Changes get deployed into environment(s) | Release Builds |
-|:--|:--|:--|
-| `master` | test and staging | *[pre-release](https://github.com/CDCgov/prime-reportstream/releases/tag/v-pre-release) (staging) |
-| `production` | production | [release](https://github.com/CDCgov/prime-reportstream/releases/latest) |
+|:-------------------------------|:--|:--|
+| `main`                         | test and staging | *[pre-release](https://github.com/CDCgov/prime-reportstream/releases/tag/v-pre-release) (staging) |
+| `production`                   | production | [release](https://github.com/CDCgov/prime-reportstream/releases/latest) |
 
 \* ⚠️*Returns "404 not found" if no changes have been merged since the last release.*
 
@@ -39,11 +39,11 @@ In preparation for our Tuesday and Thursday deployments, a cutoff time has been
 | Tuesday, 10am EST | Monday, 12pm EST |
 | Thursday, 10am EST | Wednesday, 12pm EST |
 
-The cutoff time is automatically enforced via automatic branching from `master` into a dedicated deployment branch targeting the `production` branch through a [GitHub Action](.github/workflows/prepare_deployment_branch.yaml).
+The cutoff time is automatically enforced via automatic branching from `main` into a dedicated deployment branch targeting the `production` branch through a [GitHub Action](.github/workflows/prepare_deployment_branch.yaml).
 
-1. At the specified cut-off time (Mondays and Wednesdays at noon ET), the GitHub action creates a new branch named `deployment/YYYY-MM-DD` (where the YYYY-MM-DD is `today + 1day`, i.e. the date of the deployment, not the date of the branching) which branches from `master`. This branch now contains everything that was present in `master` at that cut-off time. This is the content that is/will be part of the production deployment.
+1. At the specified cut-off time (Mondays and Wednesdays at noon ET), the GitHub action creates a new branch named `deployment/YYYY-MM-DD` (where the YYYY-MM-DD is `today + 1day`, i.e. the date of the deployment, not the date of the branching) which branches from `main`. This branch now contains everything that was present in `main` at that cut-off time. This is the content that is/will be part of the production deployment.
 1. A new PR from the deployment branch is filed to merge `deployment/YYYY-MM-DD` into `production`. The PR has title `"Deployment of YYYY-MM-DD"` and is tagged with the [`deployment` tag](https://github.com/CDCgov/prime-reportstream/issues?q=label%3Adeployment).
-1. The contents of `master` is deployed to the staging environment for verification
+1. The contents of `main` is deployed to the staging environment for verification
     * Manual testing takes place
 1. The PR is reviewed by the team
 1. The PR is merged during the specified deployment window by an approved team member.

README.md

@@ -46,8 +46,8 @@ unless pursuant to an existing contract or agreement.
 ## Privacy Standard Notice
 This repository contains only non-sensitive, publicly available data and
 information. All material and community participation is covered by the
-[Disclaimer](https://github.com/CDCgov/template/blob/master/DISCLAIMER.md)
-and [Code of Conduct](https://github.com/CDCgov/template/blob/master/code-of-conduct.md).
+[Disclaimer](https://github.com/CDCgov/template/blob/main/DISCLAIMER.md)
+and [Code of Conduct](https://github.com/CDCgov/template/blob/main/code-of-conduct.md).
 For more information about CDC's privacy policy, please visit [http://www.cdc.gov/other/privacy.html](https://www.cdc.gov/other/privacy.html).
 
 ## Contributing Standard Notice
@@ -80,6 +80,6 @@ published through the [CDC web site](http://www.cdc.gov).
 
 ## Additional Standard Notices
 Please refer to [CDC's Template Repository](https://github.com/CDCgov/template)
-for more information about [contributing to this repository](https://github.com/CDCgov/template/blob/master/CONTRIBUTING.md),
-[public domain notices and disclaimers](https://github.com/CDCgov/template/blob/master/DISCLAIMER.md),
-and [code of conduct](https://github.com/CDCgov/template/blob/master/code-of-conduct.md).
+for more information about [contributing to this repository](https://github.com/CDCgov/template/blob/main/CONTRIBUTING.md),
+[public domain notices and disclaimers](https://github.com/CDCgov/template/blob/main/DISCLAIMER.md),
+and [code of conduct](https://github.com/CDCgov/template/blob/main/code-of-conduct.md).

open_practices.md

@@ -61,7 +61,7 @@ If you are interested in using GitHub for non-open source projects, please check
 This checklist was adapted from the CDC IT Guard Rail and put here to help people who don't have access to the intranet.
 
 * [ ] Create a new project using the [template repo](https://github.com/CDCgov/template).
-* [ ] Update your readme.md following the [CDC GitHub Practices for Open Source Projects](https://github.com/CDCgov/template/blob/master/open_practices.md)
+* [ ] Update your readme.md following the [CDC GitHub Practices for Open Source Projects](https://github.com/CDCgov/template/blob/main/open_practices.md)
 * [ ] Choose a license. Most projects are ASL2, but license should meet public health program need. See <https://www.philab.cdc.gov/index.php/2012/03/27/open-source-development-for-public-health-informatics/> for more info on choosing a license.
 * [ ] Remove all sensitive info.
 * [ ] Talk with your ADI, ADS, and ISSO for review and clearance.

operations/README.md

@@ -17,7 +17,7 @@ versions all remain identical.
 > [Azure cli](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli)
 
 All infrastructure operations must be done behind the environment-specific VPN.
-You can find [directions for configuring your VPN client in prime-router/docs/VPN.md](https://github.com/CDCgov/prime-data-hub/blob/master/prime-router/docs/vpn.md).
+You can find [directions for configuring your VPN client in prime-router/docs/docs-deprecated/vpn.md](https://github.com/CDCgov/prime-reportstream/blob/main/prime-router/docs/docs-deprecated/vpn.md).
 
 ### Resource Group and KeyVault
 In order to deploy, we will need to define our resource group and keyvault. There are some specific keys we need to be pre-populated before we run our terraform as well. 
@@ -48,7 +48,7 @@ data "azurerm_key_vault_secret" "pagerduty_url" {
 
 ## Terraform
 
-For production deploys, always deploy from the `master` branch.
+For production deploys, always deploy from the `main` branch.
 
 Our Terraform code is broken down into two main folders, vars and modules. The vars direcory will contain all the variables needed for the stage you want to deploy to. All variables required to deploy that specific stage should be contained in it's respective folder. This makes it easy to determine where variables need to be changed.
 

operations/vpn/README.md

@@ -39,4 +39,4 @@
     ```
 
 ## Backup scripts
-  * [Repo](https://github.com/CDCgov/prime-reportstream/tree/master/operations/vpn)
+  * [Repo](https://github.com/CDCgov/prime-reportstream/tree/main/operations/vpn)

prime-router/docs/design/proposals/0004-git-flow-and-versioning.md

@@ -2,7 +2,7 @@
 
 To date, the PRIME Data Hub has used the following flow for code undergoing development, testing, and production:
 
-> `feature_branch(es)` --> `master` --> `production`
+> `feature_branch(es)` --> `main` --> `production`
 
 While this flow has served its purpose for the testing and validation of software changes before deployment to production, a simpler workflow that allows for the versioning of the platform is a necessary next step in its maturation.
 
@@ -33,12 +33,12 @@ The proposed versioning scheme is based off of `Calendar Versioning`<sup>1</sup>
 
 To simplify the flow of code from development to the test and production environments, the proposed flow will be:
 
-> `feature_branch(es)` --> `master`
+> `feature_branch(es)` --> `main`
 
-The `master` branch will remain protected in that:
+The `main` branch will remain protected in that:
   - It cannot be pushed to directly
   - A pull request must be submitted from the feature branch
-  - The pull request must be approved by ≥ 1 reviewer prior to being merged into the `master` branch
+  - The pull request must be approved by ≥ 1 reviewer prior to being merged into the `main` branch
 
 Upon the creation of a pull request, the `staging_build` workflow will be triggered to build and test the changes that would result from the pull request being merged.
 

prime-router/docs/design/proposals/0019-website-api-payload-structure.md

@@ -12,7 +12,7 @@ The purpose of this proposal is to align on communication between ReportStream A
     - Resource structures
     - Collection structures
 
-Having a consistent approach to the above would provide some predictability in implementation as we continue to build out the website, and it would help to simplify logic in common UX patterns like search filters and pagination.  (For example, UsePagination.ts contains [visual slot logic](https://github.com/CDCgov/prime-reportstream/blob/master/frontend-react/src/hooks/UsePagination.ts#L26-L84) that could be drastically simplified if there were, say, a `totalCount` included in the response payload.)
+Having a consistent approach to the above would provide some predictability in implementation as we continue to build out the website, and it would help to simplify logic in common UX patterns like search filters and pagination.  (For example, UsePagination.ts contains [visual slot logic](https://github.com/CDCgov/prime-reportstream/blob/main/frontend-react/src/hooks/UsePagination.ts#L26-L84) that could be drastically simplified if there were, say, a `totalCount` included in the response payload.)
 
 **NOTE: This proposal is only intended for the endpoints used by the ReportStream website.**  Although it can be argued that we'd benefit from having a consistent response payload structure across the board, updating our user-facing API signatures may create too much cascading work for our users at the moment.  (However, this could be an item we raise again if we choose to implement API versioning down the line.)
 

prime-router/docs/docs-deprecated/allowlist-gitleaks-false-positives.md

@@ -17,7 +17,7 @@ Gitleaks is configured through a [TOML](https://en.wikipedia.org/wiki/Toml) file
 It is important to understand how the different Gitleaks runs pick up the configuration that applies to each type of run:
 
 * **pre-commit hook**: uses the _configuration file from your branch_, only scans those files that are listed as staged
-* **scheduled/nightly run**: uses the _configuration file as present in the "`master`" branch_ and the rules contained in that version of the file will apply on _all_ commits that it scans in its run. This run spans _all_ commits, in _all_ branches, matching the provided (date-based) filter. In other words: your branch "`foo`" that you pushed up last night, will be scanned by the nightly run using the rules defined in the "`master`" branch! **You may have suppressed some false positives in the version of the configuration file in _your_ branch, but unless these are merged into master, they will be ignored by the scheduled run and you will still see failures.**
+* **scheduled/nightly run**: uses the _configuration file as present in the "`main`" branch_ and the rules contained in that version of the file will apply on _all_ commits that it scans in its run. This run spans _all_ commits, in _all_ branches, matching the provided (date-based) filter. In other words: your branch "`foo`" that you pushed up last night, will be scanned by the nightly run using the rules defined in the "`main`" branch! **You may have suppressed some false positives in the version of the configuration file in _your_ branch, but unless these are merged into main, they will be ignored by the scheduled run and you will still see failures.**
 
 Now that we understand how the Nightly Run picks up its configuration information, we can appreciate why there is a distinct process associated with adding suppressions to prevent unnecessary flagging of genuine False Positives by the nightly run.
 
@@ -26,7 +26,7 @@ Now that we understand how the Nightly Run picks up its configuration informatio
 The process for adding a suppression is the same, regardless of whether or not this is for work in progress, or work that's already been pushed up (regardless of its branch).
 
 * Code containing Gitleaks violations is committed in branch "`culprit`", this may or may not already have been pushed up.
-* Check out a new branch off of the "`master`" branch (let's call this one "`gitleaks-culprit`").
+* Check out a new branch off of the "`main`" branch (let's call this one "`gitleaks-culprit`").
 * In "`gitleaks-culprit`", modify the `gitleaks-config.toml` file to have the correct suppressions.
 * Push up the "`gitleaks-culprit`" branch and open a Pull Request, include at least one member of the DevOps team (e.g. @CDCgov/prime-reportstream-devops). The Pull Request _must_ contain an explanation of:
     * What you are suppressing and why it's ok: the specific patterns/values/commits; example:
@@ -35,8 +35,8 @@ The process for adding a suppression is the same, regardless of whether or not t
         * "This commit does not contain any other code except for the addition of test keys, there is nothing else in this commit to be flagged. The suppression disables this particular rule for just this commit. Other rules still apply."
     * Why the suppression will not cause False Negatives; example:
         * "Suppressing the pattern "`it\.key\.contains\(`" in the "Generic Credential" rule set is fine because this value is not a credential, it is a key lookup in an iterator."
-* Get approval for the PR and merge the PR into "`master`" on approval by at least one member of the DevOps team, when the nightly run kicks off, it will now have your suppression(s) applied and not raise a false positive on the changes in your branch.
-* To bring the suppression into your own branch, either `git merge master` into your branch or `git cherrypick` the commit that contains the suppression on to your branch.
+* Get approval for the PR and merge the PR into "`main`" on approval by at least one member of the DevOps team, when the nightly run kicks off, it will now have your suppression(s) applied and not raise a false positive on the changes in your branch.
+* To bring the suppression into your own branch, either `git merge main` into your branch or `git cherrypick` the commit that contains the suppression on to your branch.
 
 # How to Suppress
 

prime-router/docs/docs-deprecated/how-to-onboard-a-receiver.md

@@ -54,7 +54,7 @@ Below is an example of the organization file
 
 In the above example, the jurisdictional filter searches the `ordering_facility_state` field in the report for anything 
 that matches the code LT. Filters can be applied to the organization or receiver. For more information on filters see: 
-(https://github.com/CDCgov/prime-reportstream/blob/master/prime-router/docs/playbooks/how-to-use-filters.md)
+(https://github.com/CDCgov/prime-reportstream/blob/main/prime-router/docs/playbooks/how-to-use-filters.md)
 
 In addition, there is the translation section, which specifies the output format that will be sent to the receiver. 
 Currently, we have three formats available:
@@ -109,10 +109,10 @@ The mechanism for how each record is translated is laid out in the schema, which
 By default, any HL7 receiver will use the COVID-19 schema and you do not need to create a schema
 specific to your receiver. If they are going to receive a CSV file you *MUST* create a schema. In lieu
 of a schema, we use the `TranslationConfig` to set default values and control HL7 processing. 
-(https://github.com/CDCgov/prime-reportstream/blob/master/prime-router/docs/playbooks/how_to_use_translation_configuration_features.md)
+(https://github.com/CDCgov/prime-reportstream/blob/main/prime-router/docs/playbooks/how_to_use_translation_configuration_features.md)
 
 For additional information on creating a schema see: 
-(https://github.com/CDCgov/prime-reportstream/blob/master/prime-router/docs/how-to-onboard-a-sender.md)
+(https://github.com/CDCgov/prime-reportstream/blob/main/prime-router/docs/how-to-onboard-a-sender.md)
 
 ### Generate test data
 
@@ -151,7 +151,7 @@ If you want to create the data as HL7, that is easy to do as well:
 - Once you've got the kinks out of the organizations.yml, carefully update settings in the staging environment. 
   - `./prime multiple-settings set --help`
 - Create a PR for the change, review, and push. The review is a good chance for someone to doublecheck the filters.
-- It should deploy to staging automagically once the PR is approved and merged into master.
+- It should deploy to staging automagically once the PR is approved and merged into main.
 - Test again in Staging
 - If you are ready, carefully update settings in the prod environment. Especially in production, check the batch 
 timing. NOT every minute, eh?