Change 'master' references to 'main'.

Author: Benjamin A. Stockwell

.circleci/config.yml

@@ -87,9 +87,7 @@ workflows:
             - build
           filters:
             branches:
-              only: master
+              only: main
       - upload-codecov:
           requires:
             - build
-
-

.github/release-drafter.yml

@@ -1,7 +1,7 @@
 name-template: 'v$NEXT_PATCH_VERSION'
 tag-template: 'v$NEXT_PATCH_VERSION'
 change-template: '*#$NUMBER - $TITLE'
-branches: master
+branches: main
 categories:
   - title: 'Features 🚀'
     labels:
@@ -20,4 +20,3 @@ template: |
   $CHANGES
 
   Release Contributors: $CONTRIBUTORS
-

CONTRIBUTING.md

@@ -74,7 +74,7 @@ Here are the steps to running the tests for SSO:
 
 Changes to `buzzfeed/sso` happen via GitHub pull requests, which is where at least one other engineer reviews and approves all code changes. Some tips for pull requests and code review:
 
-* Each pull request is a branch from `master` — there are no other long-lived branches
+* Each pull request is a branch from `main` — there are no other long-lived branches
 * A single pull request is used for each set of changes — i.e., once a pull request has been opened, any follow-up commits to address code review and discussion should be pushed to that pull request instead of a new one
 * Before a pull request is merged, it must get a green check mark from our CI for passing tests
 * Before a pull request is merged, the author should take the opportunity to clean up and rewrite the commits on the branch (see [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/).
@@ -92,4 +92,4 @@ In order to allow SSO to be the most useful, while balancing feature needs with
 * We will do our best to merge every contribution that enables a requested feature or solves an issue that blocks folks using SSO.
 * As we find more efficient, secure, or otherwise stronger solutions, we will deprecate old features and replace them.
 
-Our strategy will be to announce deprecation as part of a stable release, and remove functionality as part of the next stable release. While this is a very quick cycle, we believe it is the best approach for keeping SSO up to date and preventing reliance on outdated featuresets.
+Our strategy will be to announce deprecation as part of a stable release, and remove functionality as part of the next stable release. While this is a very quick cycle, we believe it is the best approach for keeping SSO up to date and preventing reliance on outdated featuresets.

README.md

@@ -5,7 +5,7 @@
 [![CircleCI](https://circleci.com/gh/buzzfeed/sso.svg?style=svg)](https://circleci.com/gh/buzzfeed/sso)
 [![MIT license](http://img.shields.io/badge/license-MIT-brightgreen.svg)](http://opensource.org/licenses/MIT)
 [![Docker Automated build](https://img.shields.io/docker/automated/buzzfeed/sso.svg)](https://hub.docker.com/r/buzzfeed/sso/)
-[![codecov.io](https://codecov.io/github/buzzfeed/sso/coverage.svg?branch=master)](https://codecov.io/github/buzzfeed/sso?branch=master)
+[![codecov.io](https://codecov.io/github/buzzfeed/sso/coverage.svg?branch=main)](https://codecov.io/github/buzzfeed/sso?branch=main)
 
 
 <img src="https://user-images.githubusercontent.com/10510566/44476420-a64e5980-a605-11e8-8ad9-2820109deb75.png" width="128px">

docs/okta_provider_setup.md

@@ -49,7 +49,7 @@ For 'Platform', choose `Web`, and for 'Sign on method' choose `OpenID Connect`.
     `https://sso-auth.example.com/okta/callback`. Multiple URIs can be added if required.
 -  **Logout redirect URIs**: This can be left blank.
 
-**⚡️ Note**: If you're following the [Quickstart guide](https://github.com/buzzfeed/sso/blob/master/docs/quickstart.md), use `http://sso-auth.localtest.me/okta/callback` as the Authorized redirect URI.
+**⚡️ Note**: If you're following the [Quickstart guide](https://github.com/buzzfeed/sso/blob/main/docs/quickstart.md), use `http://sso-auth.localtest.me/okta/callback` as the Authorized redirect URI.
 
 ## 4. Finish configuring your Application
 
@@ -66,8 +66,8 @@ and make sure `Refresh Token` is checked under 'Client acting on behalf of a use
 At the bottom of this same page you will see a section called 'Client Credentials' containing a `Client ID` and a `Client secret`.
 Copy both of these values to a safe and secure location - these are required to configure your `sso` deployment.
 
-**⚡️Note:**  If you're following the  [Quickstart guide](https://github.com/buzzfeed/sso/blob/master/docs/quickstart.md),  **stop here!**
-You'll add these credentials to  `quickstart/env`  as instructed in  [the guide](https://github.com/buzzfeed/sso/blob/master/docs/quickstart.md).
+**⚡️Note:**  If you're following the  [Quickstart guide](https://github.com/buzzfeed/sso/blob/main/docs/quickstart.md),  **stop here!**
+You'll add these credentials to  `quickstart/env`  as instructed in  [the guide](https://github.com/buzzfeed/sso/blob/main/docs/quickstart.md).
 
 ### Assignments
 

docs/sso_authenticator_config.md

@@ -2,7 +2,7 @@
 We currently use environment variables to read configuration options, below is a list of environment variables and
 their corresponding types that the sso authenticator will read.
 
-Defaults for the below settings can be found here: https://github.com/buzzfeed/sso/blob/master/internal/auth/configuration.go#L66-L117
+Defaults for the below settings can be found here: https://github.com/buzzfeed/sso/blob/main/internal/auth/configuration.go#L66-L117
 
 
 ## Session and Server configuration

docs/sso_config.md

@@ -99,7 +99,7 @@ export SSO_CONFIG_FOOBAR_SIGNING_KEY="sha256:shared-secret-value"
 ```
 would be the signing key for the `foobar` upstream service, use the sha256 with the `shared-secret-value` as it's signing key value.
 
-This signs the request using defined signature headers found in https://github.com/buzzfeed/sso/blob/master/sso_proxy/oauthproxy.go#L25.
+This signs the request using defined signature headers found in https://github.com/buzzfeed/sso/blob/main/sso_proxy/oauthproxy.go#L25.
 Specific implementation details can be found at https://github.com/18F/hmacauth
 
 ### Headers