Change master to main (#1565)

* Change master to main

Signed-off-by: Gerred Dillon <hello@gerred.org>

* fixes to incorrectly replaced values out of our control

Signed-off-by: Ken Sipe <kensipe@gmail.com>

Co-authored-by: Ken Sipe <kensipe@gmail.com>

.github/ISSUE_TEMPLATE/bug_report.md

@@ -8,7 +8,7 @@ assignees: ''
 ---
 
 <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!
-If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/master/SECURITY_CONTACTS
+If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS
 -->
 
 

.github/ISSUE_TEMPLATE/enhancement-request.md

@@ -8,7 +8,7 @@ assignees: ''
 ---
 
 <!-- Please only use this template for submitting enhancement requests.
-Implementing your enhancement will follow the KEP process: https://github.com/kudobuilder/kudo/blob/master/keps/0001-kep-process.md
+Implementing your enhancement will follow the KEP process: https://github.com/kudobuilder/kudo/blob/main/keps/0001-kep-process.md
 -->
 
 **What would you like to be added**:

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,6 +1,6 @@
 <!--  Thanks for sending a pull request!  Here are some tips for you:
 
-1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/master/CONTRIBUTING.md
+1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
 2. Make sure you have added and ran the tests before submitting your PR
 3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/
 -->

.github/workflows/release-drafter.yml

@@ -4,13 +4,13 @@ on:
   push:
     # branches to consider in the event; optional, defaults to all
     branches:
-      - master
+      - main
 
 jobs:
   update_release_draft:
     runs-on: ubuntu-latest
     steps:
-      # Drafts your next Release notes as Pull Requests are merged into "master"
+      # Drafts your next Release notes as Pull Requests are merged into "main"
       - uses: release-drafter/release-drafter@v5.6.1
         with:
           # (Optional) specify config name to use, relative to .github/. Default: release-drafter.yml

.github/workflows/release-on-master.yml

@@ -1,8 +1,8 @@
-name: Release Master Snapshot
+name: Release Main Snapshot
 on:
   push:
     branches:
-      - master
+      - main
 jobs:
   build:
     runs-on: ubuntu-latest
@@ -27,16 +27,16 @@ jobs:
              --build-arg git_version_arg=github.com/kudobuilder/kudo/pkg/version.gitVersion=v$GITHUB_SHA \
             --build-arg git_commit_arg=github.com/kudobuilder/kudo/pkg/version.gitCommit=$GITHUB_SHA \
             --build-arg build_date_arg=github.com/kudobuilder/kudo/pkg/version.buildDate=$BUILD_DATE . -t docker.pkg.github.com/$REPOSITORY:$GITHUB_SHA
-      - name: Tag with `master`
+      - name: Tag with `main`
         env:
           REPOSITORY: ${{ secrets.REPOSITORY }}
         run: |
-            docker tag docker.pkg.github.com/$REPOSITORY:$GITHUB_SHA docker.pkg.github.com/$REPOSITORY:master
+          docker tag docker.pkg.github.com/$REPOSITORY:$GITHUB_SHA docker.pkg.github.com/$REPOSITORY:main
       - name: Push image with commit SHA
         env:
           REPOSITORY: ${{ secrets.REPOSITORY }}
         run: docker push docker.pkg.github.com/$REPOSITORY:$GITHUB_SHA
-      - name: Push master tag
+      - name: Push main tag
         env:
           REPOSITORY: ${{ secrets.REPOSITORY }}
-        run: docker push docker.pkg.github.com/$REPOSITORY:master
+        run: docker push docker.pkg.github.com/$REPOSITORY:main

CONTRIBUTING.md

@@ -24,7 +24,7 @@ You can find the full text of the DCO here: https://developercertificate.org/
 ## Contributing Steps
 
 1. Submit an issue describing your proposed change to the repo in question.
-2. The [repo owners](https://github.com/kudobuilder/kudo/blob/master/.github/CODEOWNERS) will respond to your issue promptly.
+2. The [repo owners](https://github.com/kudobuilder/kudo/blob/main/.github/CODEOWNERS) will respond to your issue promptly.
 3. If your proposed change is accepted, and you haven't already done so, sign a Contributor License Agreement (see details above).
 4. Fork the desired repo, develop and test your code changes.
 5. Submit a pull request.
@@ -46,7 +46,7 @@ You can find the full text of the DCO here: https://developercertificate.org/
 - `make all` to build manager as well as CLI
 - [optionally] `make docker-build` to build the manager Docker images
 
-When updating the structs under [APIs](https://github.com/kudobuilder/kudo/blob/master/pkg/apis/), or any other code generated item, use `make generate` to generate the new DeepCopy structs.
+When updating the structs under [APIs](https://github.com/kudobuilder/kudo/blob/main/pkg/apis/), or any other code generated item, use `make generate` to generate the new DeepCopy structs.
 
 #### Running manager locally
 The most convenient way to test new controller code is to run the manager locally. It will use kubernetes cluster defined via your local kubeconfig to talk to API server and resolve CRDs. You can run manager locally via `make run`.
@@ -64,7 +64,7 @@ For some situations, it might make sense to test your manager inside a real clus
 
 ### Testing
 
-See the [contributor's testing guide](https://github.com/kudobuilder/kudo/blob/master/test/README.md).
+See the [contributor's testing guide](https://github.com/kudobuilder/kudo/blob/main/test/README.md).
 
 ## Community, Discussion, and Support
 
@@ -80,15 +80,15 @@ You can reach the maintainers of this project at:
 This is a set of practices we try to live by when developing KUDO. These are just defaults (soft rules). Deviations from them are possible, but have to be justified.
 
 ### General guidelines
-- Master is always releasable (green CI)
+- Main is always releasable (green CI)
 - All feature/bug-fixing work should have an open issue with a description, unless it's something very simple
 - Every user-facing feature that is NOT behind a feature gate should have integration or an e2e test
 
 ### Pull requests
 - One core-team member has to approve the PR to be able to merge (all people listed in `.github/CODEOWNERS` file)
 - One approval is enough to merge. However, if there are requests for change they have to be resolved prior to the merge
 - Since KUDO is developed in multiple timezones, try to keep the PR open for everyone to be able to see it (~24h, keep in mind public holidays)
-- We prefer squash commits so that all changes from a branch are committed to master as a single commit
+- We prefer squash commits so that all changes from a branch are committed to main as a single commit
 - Before you merge, make sure your commit title and description are meaningful. Github by default will list all the individual PR commits when squashing which are rarely insightful. We aim for a clean and meaningful commit history. 
 - Labels: If your PR includes either **breaking changes** or should get additional attention in the release, add one of these label:
   - `release/highlight` For a big new feature, an important bug fix, the focus of the current release
@@ -123,7 +123,7 @@ It is unlikely an enhancement if it is:
 - performance improvements, which are only visible to users as faster API operations, or faster control loops
 - adding error messages or events
 
-If you are not sure, ask someone in the [#kudo](https://kubernetes.slack.com/messages/kudo/) channel on Slack or ping someone listed in [CODEOWNERS](https://github.com/kudobuilder/kudo/blob/master/.github/CODEOWNERS).
+If you are not sure, ask someone in the [#kudo](https://kubernetes.slack.com/messages/kudo/) channel on Slack or ping someone listed in [CODEOWNERS](https://github.com/kudobuilder/kudo/blob/main/.github/CODEOWNERS).
 
 ### When to Create a New Enhancement Issue
 
@@ -139,4 +139,4 @@ Create an issue in this repo once you:
 
 ## Code of Conduct
 
-Participation in the Kubernetes community is governed by the [Kubernetes Code of Conduct](https://github.com/kudobuilder/kudo/blob/master/code-of-conduct.md).
+Participation in the Kubernetes community is governed by the [Kubernetes Code of Conduct](https://github.com/kudobuilder/kudo/blob/main/code-of-conduct.md).

RELEASE.md

@@ -2,22 +2,22 @@
 
 ## Development Processes
 
-### Master
+### Main
 
-The `HEAD` of `master` branch is considered the most active development, to which new features and bug fixes are applied. The expectation is that master will always build and pass tests.
+The `HEAD` of `main` branch is considered the most active development, to which new features and bug fixes are applied. The expectation is that main will always build and pass tests.
 Development is incremental. It is expected that pull-requests are either:
  - complete and fully integrated into code execution path, or
  - have a feature switch which must be enabled until code completion is reached.
 
-`HEAD` on master is expected to be in a state that it could be released.
-The next major release will be tagged and released from master.
-If the current released version is `v0.3.1` and the next major release is `v0.4.0`, then when it is deemed appropriate `v0.4.0` will be tagged off master, followed by a release.
-From that tag work will continue on master.
+`HEAD` on main is expected to be in a state that it could be released.
+The next major release will be tagged and released from main.
+If the current released version is `v0.3.1` and the next major release is `v0.4.0`, then when it is deemed appropriate `v0.4.0` will be tagged off main, followed by a release.
+From that tag work will continue on main.
 
 *If* it is necessary in the future to have a patch release for `v0.4.1`, a branch will be created off the `v0.4.0` tag with the nomenclature of `releases/{major.minor}`, in this example `releases/0.4`.
 Branches matching `releases/*` are protected branches in the repository.
 
-The `HEAD` of the release branches follows the same conventions as master.  It is expected that `HEAD` of the release branch is always in a releasable state. The purpose of the release branch is for bug fixes only.  New features should not be targeted to a release branch.
+The `HEAD` of the release branches follows the same conventions as main.  It is expected that `HEAD` of the release branch is always in a releasable state. The purpose of the release branch is for bug fixes only.  New features should not be targeted to a release branch.
 
 ### Documentation
 
@@ -34,7 +34,7 @@ what the exact version number will be up-front.
 
 ### Bug Fixes
 
-Bug fixes are expected to be worked on and applied to `master`.
+Bug fixes are expected to be worked on and applied to `main`.
 
 If the fix is needed for a previously supported release version of KUDO, then a backport is expected.
 The bug fix pull request is expected to be marked with a `backport` label.
@@ -70,15 +70,15 @@ The token must grant full access to: `repo`, `write:packages`, `read:packages`.
 1. Invoke goreleaser `goreleaser --rm-dist`.
 1. Update the GH release with release highlights. There is a draft that contains categorized changes since the last release. It provides categories for highlights, breaking changes, and contributors which should be added the gorelease release notes. The changelog from the draft log is ignored. After the contents are copied, the draft can be deleted.
 1. Merge the [branch](#documentation) of the [`kudo.dev`](https://github.com/kudobuilder/kudo.dev) repo dedicated to current release
-   into `master`, following the regular GitHub pull request process.
+   into `main`, following the regular GitHub pull request process.
 1. Immediately after that, create a `post-v0.2.0` branch for documentation for a *future* release
-   from the tip of `master` of the [`kudo.dev`](https://github.com/kudobuilder/kudo.dev) repo,
+   from the tip of `main` of the [`kudo.dev`](https://github.com/kudobuilder/kudo.dev) repo,
    for example in the GitHub UI:
 
    ![img](.github/new-branch.png)
 1. Send an announcement email to [kudobuilder@googlegroups.com](https://groups.google.com/forum/#!forum/kudobuilder) with the subject `[ANNOUNCE] Kudo $VERSION is released`
 1. Run `./hack/generate_krew.sh` and submit the generated `kudo.yaml` to https://github.com/kubernetes-sigs/krew-index/.
-1. Update KUDO_VERSION [in the Makefile](https://github.com/kudobuilder/operators/blob/master/Makefile#L2) of operators repo
+1. Update KUDO_VERSION [in the Makefile](https://github.com/kudobuilder/operators/blob/main/Makefile#L2) of operators repo
 
 **Note:** If there are issues with the release, any changes to the repository will result in it being considered "dirty" and not in a state to be released.
 It is possible outside of the standard release process to build a "snapshot" release using the following command: `goreleaser release --skip-publish --snapshot --rm-dist`
@@ -88,11 +88,11 @@ This process will create a `dist` folder with all the build artifacts. The chang
 
 ### Cutting a Release Branch
 
-As outlined above, when it is necessary to create a new release branch, it is necessary to update the [circle-ci config](https://github.com/kudobuilder/kudo/blob/master/.circle-ci/config.yml#L13) to test merges against the correct branch. It is necessary replace all references to `master` with the appropriate release branch.
+As outlined above, when it is necessary to create a new release branch, it is necessary to update the [circle-ci config](https://github.com/kudobuilder/kudo/blob/main/.circle-ci/config.yml#L13) to test merges against the correct branch. It is necessary replace all references to `main` with the appropriate release branch.
 
 ### Cutting a Patch Release
 
-When cutting a patch release, for example `v0.3.3`, it is necessary to ensure that all bugs fixed on master after `v0.3.2` have landed on the release branch, `releases/0.3` in this case.
+When cutting a patch release, for example `v0.3.3`, it is necessary to ensure that all bugs fixed on main after `v0.3.2` have landed on the release branch, `releases/0.3` in this case.
 
 ### Cutting a pre-release
 

keps/0004-add-testing-infrastructure.md

@@ -29,7 +29,7 @@ status: implementable
    * [Kubernetes clusters](0004-add-testing-infrastructure.md#kubernetes-clusters)
    * [CICD](#cicd)
       * [Pull Requests](#pull-requests)
-      * [Master Branch](#master-branch)
+      * [Main Branch](#main-branch)
          * [Tests](#tests-1)
          * [Pushes](#pushes)
          * [Schedule](#schedule)
@@ -49,7 +49,7 @@ As the complexity and scope of KUDO grows, it becomes impossible to manually val
 
 These testing packages should also assure conformance for the `kudobuilder/operators` repository to particular versions of KUDO.
 
-[KEP-0008](https://github.com/kudobuilder/kudo/blob/master/keps/0008-operator-testing.md) outlines the design of a testing harness for validating KUDO and operators. This document outlines testing procedures and policies - e.g., what, where, when and how we will test.
+[KEP-0008](https://github.com/kudobuilder/kudo/blob/main/keps/0008-operator-testing.md) outlines the design of a testing harness for validating KUDO and operators. This document outlines testing procedures and policies - e.g., what, where, when and how we will test.
 
 ## Motivation
 
@@ -97,11 +97,11 @@ Integration tests will be hidden behind a Go build tag and will only run when th
 
 End to end tests test the KUDO controller on a real Kubernetes cluster (either kubernetes-in-docker or any other Kubernetes cluster). These should exercise KUDO's features and workflows including installing operators from the repository. End-to-end tests can also exercise the CLI to test CLI-based workflows.
 
-End-to-end tests will be triggered on merge to master, for release pull requests, and manually for pull requests containing risky or major changes.
+End-to-end tests will be triggered on merge to main, for release pull requests, and manually for pull requests containing risky or major changes.
 
 #### Operator tests
 
-Operator tests test that an operator works correctly. These require a full Kubernetes cluster to run and will be run in CI for the Operators repository using the latest released version of KUDO. Instead of running every test on every pull request, we will only run the tests that test the operator changed in any given pull request. Operator tests will also be run against master and release builds of KUDO to verify that KUDO changes do not break operators. Operators are tested using the KUDO test harness from KEP-0008.
+Operator tests test that an operator works correctly. These require a full Kubernetes cluster to run and will be run in CI for the Operators repository using the latest released version of KUDO. Instead of running every test on every pull request, we will only run the tests that test the operator changed in any given pull request. Operator tests will also be run against main and release builds of KUDO to verify that KUDO changes do not break operators. Operators are tested using the KUDO test harness from KEP-0008.
 
 Operator tests will also be run in CI for the KUDO repository manually after review, but prior to merging using `/test` command supported by Prow.
 
@@ -126,7 +126,7 @@ CICD is accomplished by a combination of CircleCI and Github Actions enabled for
 
 #### Pull Requests
 
-All Pull Requests into master need to have the following checks pass. These should be ordered in fastest to slowest to reduce the time spent when/if failures occur.
+All Pull Requests into main need to have the following checks pass. These should be ordered in fastest to slowest to reduce the time spent when/if failures occur.
 
 0. Check author has signed CLA
 1. If the user is not a contributor, a contributor must write `/ok-to-test` on the pull request before it will be triggered.
@@ -136,17 +136,17 @@ All Pull Requests into master need to have the following checks pass. These shou
 1. Dockerfile builds (this requires all dependencies in the vendor folder)
 1. All integration tests pass.
 
-Perform the same set of tests after merging master into the branch.
+Perform the same set of tests after merging main into the branch.
 
-#### Master Branch
+#### Main Branch
 
 ##### Tests
 
-The master branch will run all the same tests that pull requests do as well as the complete set of operator tests.
+The main branch will run all the same tests that pull requests do as well as the complete set of operator tests.
 
 ##### Pushes
 
-Once merged into master a build process occurs to deploy the latest image at `kudobuilder/controller:latest`
+Once merged into main a build process occurs to deploy the latest image at `kudobuilder/controller:latest`
 
 ##### Schedule
 

keps/0008-operator-testing.md

@@ -388,4 +388,4 @@ Controllers are typically tested using test libraries in the same language that
 
 ## Infrastructure Needed
 
-A CI system and cloud infrastructure for running the test suite are required (see [0004-add-testing-infrastructure](https://github.com/kudobuilder/kudo/blob/master/keps/0004-add-testing-infrastructure.md)).
+A CI system and cloud infrastructure for running the test suite are required (see [0004-add-testing-infrastructure](https://github.com/kudobuilder/kudo/blob/main/keps/0004-add-testing-infrastructure.md)).

keps/0010-package-manager.md

@@ -39,7 +39,7 @@ status: implementable
 
 As more and more developers seed our `kubebuilder/operators` repository with incredibly important Operators, we need to define how these operators will be made available.
 
-This KEP aims to define an operator repository structure. This structure indirectly impacts other KEPs, e.g., [KEP-0003 CLI](https://github.com/kudobuilder/kudo/blob/master/keps/0003-kep-cli.md), [KEP-0007 CLI Generation](https://github.com/kudobuilder/kudo/blob/master/keps/0007-cli-generation.md) or [KEP-0008 Operator Testing](https://github.com/kudobuilder/kudo/blob/master/keps/0008-operator-testing.md).
+This KEP aims to define an operator repository structure. This structure indirectly impacts other KEPs, e.g., [KEP-0003 CLI](https://github.com/kudobuilder/kudo/blob/main/keps/0003-kep-cli.md), [KEP-0007 CLI Generation](https://github.com/kudobuilder/kudo/blob/main/keps/0007-cli-generation.md) or [KEP-0008 Operator Testing](https://github.com/kudobuilder/kudo/blob/main/keps/0008-operator-testing.md).
 
 Overall, this KEP captures how we plan to provide a great user experience for installing Operators with KUDO. It focuses on: