*: replace occurance of master branch with main branch

Signed-off-by: paulfantom <pawel@krupa.net.pl>

.mdox.validate.yaml

@@ -13,3 +13,6 @@ validators:
   # Ignore release links.
   - regex: 'https:\/\/github\.com\/prometheus-operator\/prometheus-operator\/releases'
     type: "ignore"
+  # Ignore GitHub container packages link as it returns 404 in curl, but works in browser
+  - regex: 'https://github.com/prometheus-operator/prometheus-operator/pkgs/container/prometheus-operator'
+    type: "ignore"

CONTRIBUTING.md

@@ -47,7 +47,7 @@ are very busy and read the mailing lists.
 
 This is a rough outline of what a contributor's workflow looks like:
 
-- Create a topic branch from where you want to base your work (usually master).
+- Create a topic branch from where you want to base your work (usually `main`).
 - Make commits of logical units.
 - Make sure your commit messages are in the proper format (see below).
 - Push your changes to a topic branch in your fork of the repository.

Documentation/design.md

@@ -45,7 +45,7 @@ When there are two or more configured replicas the operator runs the Alertmanage
 
 ## ThanosRuler
 
-The `ThanosRuler` custom resource definition (CRD) declaratively defines a desired [Thanos Ruler](https://github.com/thanos-io/thanos/blob/master/docs/components/rule.md) setup to run in a Kubernetes cluster. With Thanos Ruler recording and alerting rules can be processed across multiple Prometheus instances.
+The `ThanosRuler` custom resource definition (CRD) declaratively defines a desired [Thanos Ruler](https://github.com/thanos-io/thanos/blob/main/docs/components/rule.md) setup to run in a Kubernetes cluster. With Thanos Ruler recording and alerting rules can be processed across multiple Prometheus instances.
 
 A `ThanosRuler` instance requires at least one `queryEndpoint` which points to the location of Thanos Queriers or Prometheus instances. The `queryEndpoints` are used to configure the `--query` arguments(s) of the Thanos runtime.
 Further information can also be found in the [Thanos doc](thanos.md).

Documentation/thanos.md

@@ -57,7 +57,7 @@ In this mode, sidecar assumes an existing Kubernetes Secret containing the Thano
 Inside this secret you configure how to run Thanos with your object storage.
 
 For more information and examples about the configuration itself, take a look at the Thanos documentation:
-https://github.com/thanos-io/thanos/blob/master/docs/storage.md
+https://github.com/thanos-io/thanos/blob/main/docs/storage.md
 
 Once you have written your configuration save it to a file.
 Here's an example:
@@ -99,7 +99,7 @@ responsible for compactions on a global, object storage level.
 
 ## Thanos Ruler
 
-The [Thanos Ruler](https://github.com/thanos-io/thanos/blob/master/docs/components/rule.md) component allows recording and alerting rules to be processed across
+The [Thanos Ruler](https://github.com/thanos-io/thanos/blob/main/docs/components/rule.md) component allows recording and alerting rules to be processed across
 multiple Prometheus instances. A `ThanosRuler` instance requires at least one `queryEndpoint` which points to the location of Thanos Queriers or Prometheus instances. The `queryEndpoints` are used to configure the `--query` arguments(s) of the Thanos runtime.
 
 ```yaml

Documentation/user-guides/exposing-prometheus-and-alertmanager.md

@@ -85,7 +85,7 @@ The Alertmanager web UI will be available at `http://<node-ip>:30903/`.
 The Kubernetes API has a feature of forwarding requests from the API to a cluster internal Service. The general URL scheme to access these is:
 
 ```
-http(s)://master-host/api/v1/proxy/namespaces/<namespace>/services/<service-name>:<port-name-or-number>/
+http(s)://control-plane-host/api/v1/proxy/namespaces/<namespace>/services/<service-name>:<port-name-or-number>/
 ```
 
 > For ease of use, use `kubectl proxy`. It proxies requests from a local address to the Kubernetes API server and handles authentication.
@@ -167,7 +167,7 @@ Then it will be available under http://127.0.0.1:8001/api/v1/proxy/namespaces/de
 
 Exposing the Prometheus or Alertmanager web UI through an Ingress object requires a running Ingress controller. For more information, see the Kubernetes documentation on [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/).
 
-This example was tested with the [NGINX Ingress Controller](https://github.com/kubernetes/ingress-nginx). For a quick-start for running the NGINX Ingress Controller follow the instructions in the [NGINX Ingress installation guide](https://github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md).
+This example was tested with the [NGINX Ingress Controller](https://github.com/kubernetes/ingress-nginx). For a quick-start for running the NGINX Ingress Controller follow the instructions in the [NGINX Ingress installation guide](https://github.com/kubernetes/ingress-nginx/blob/main/docs/deploy/index.md).
 
 > Be certain to evaluate available Ingress controllers for the specifics of your production environment. The NGINX Ingress Controller may or may not be suitable. Consider other solutions, like HA Proxy, Traefik, GCE, or AWS.
 

Documentation/user-guides/storage.md

@@ -29,7 +29,7 @@ parameters:
 
 For best results, use volumes that have high I/O throughput. These examples use SSD EBS volumes. Read the Kubernetes [Persistent Volumes](https://kubernetes.io/docs/user-guide/persistent-volumes/#aws) documentation to adapt this `StorageClass` to your needs.
 
-The `StorageClass` that was created can be specified in the `storage` section in the `Prometheus` resource (note that if you're using [kube-prometheus](https://github.com/prometheus-operator/kube-prometheus), then instead of making the following change to your `Prometheus` resource, see the [prometheus-pvc.jsonnet](https://github.com/prometheus-operator/kube-prometheus/blob/master/examples/prometheus-pvc.jsonnet) example).
+The `StorageClass` that was created can be specified in the `storage` section in the `Prometheus` resource (note that if you're using [kube-prometheus](https://github.com/prometheus-operator/kube-prometheus), then instead of making the following change to your `Prometheus` resource, see the [prometheus-pvc.jsonnet](https://github.com/prometheus-operator/kube-prometheus/blob/main/examples/prometheus-pvc.jsonnet) example).
 
 ```yaml mdox-exec="cat example/storage/persisted-prometheus.yaml"
 apiVersion: monitoring.coreos.com/v1

README.md

@@ -25,7 +25,7 @@ The Prometheus operator includes, but is not limited to, the following features:
 * **Prometheus Target Configuration**: Automatically generate monitoring target configurations based
   on familiar Kubernetes label queries; no need to learn a Prometheus specific configuration language.
 
-For an introduction to the Prometheus Operator, see the [getting started](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/getting-started.md) guide.
+For an introduction to the Prometheus Operator, see the [getting started](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/user-guides/getting-started.md) guide.
 
 ## Prometheus Operator vs. kube-prometheus vs. community helm chart
 

RELEASE.md

@@ -1,6 +1,6 @@
 # Release schedule
 
-Following [Prometheus](https://github.com/prometheus/prometheus/blob/master/RELEASE.md) and [Thanos](https://github.com/thanos-io/thanos/blob/master/docs/release-process.md), this project aims for a predictable release schedule.
+Following [Prometheus](https://github.com/prometheus/prometheus/blob/main/RELEASE.md) and [Thanos](https://github.com/thanos-io/thanos/blob/main/docs/release-process.md), this project aims for a predictable release schedule.
 
 Release cadence of first pre-releases being cut is 6 weeks.
 
@@ -26,7 +26,7 @@ Release cadence of first pre-releases being cut is 6 weeks.
 
 # How to cut a new release
 
-> This guide is strongly based on the [Prometheus release instructions](https://github.com/prometheus/prometheus/blob/master/RELEASE.md).
+> This guide is strongly based on the [Prometheus release instructions](https://github.com/prometheus/prometheus/blob/main/RELEASE.md).
 
 ## Branch management and versioning strategy
 
@@ -34,15 +34,15 @@ We use [Semantic Versioning](http://semver.org/).
 
 We maintain a separate branch for each minor release, named `release-<major>.<minor>`, e.g. `release-1.1`, `release-2.0`.
 
-The usual flow is to merge new features and changes into the master branch and to merge bug fixes into the latest release branch. Bug fixes are then merged into master from the latest release branch. The master branch should always contain all commits from the latest release branch.
+The usual flow is to merge new features and changes into the `main` branch and to merge bug fixes into the latest release branch. Bug fixes are then merged into `main` from the latest release branch. The `main` branch should always contain all commits from the latest release branch.
 
-If a bug fix got accidentally merged into master, cherry-pick commits have to be created in the latest release branch, which then have to be merged back into master. Try to avoid that situation.
+If a bug fix got accidentally merged into `main`, cherry-pick commits have to be created in the latest release branch, which then have to be merged back into `main`. Try to avoid that situation.
 
 Maintaining the release branches for older minor releases happens on a best effort basis.
 
 ## Update Go dependencies
 
-A couple of days before the release, consider submitting a PR against the `master` branch to update the Go dependencies.
+A couple of days before the release, consider submitting a PR against the `main` branch to update the Go dependencies.
 
 ```bash
 make update-go-deps
@@ -54,7 +54,7 @@ A couple of days before the release, update the [default versions](https://githu
 
 ## Prepare your release
 
-For a new major or minor release, work from the `master` branch. For a patch release, work in the branch of the minor release you want to patch (e.g. `release-0.43` if you're releasing `v0.43.2`).
+For a new major or minor release, work from the `main` branch. For a patch release, work in the branch of the minor release you want to patch (e.g. `release-0.43` if you're releasing `v0.43.2`).
 
 Bump the version in the `VERSION` file in the root of the repository.
 
@@ -106,11 +106,11 @@ git push origin "${tag}" "pkg/apis/monitoring/${tag}" "pkg/client/${tag}"
 
 Signed tag with a GPG key is appreciated, but in case you can't add a GPG key to your Github account using the following [procedure](https://help.github.com/articles/generating-a-gpg-key/), you can replace the `-s` flag by `-a` flag of the `git tag` command to only annotate the tag without signing.
 
-Our CI pipeline will automatically push the container images to [quay.io](https://quay.io/organization/prometheus-operator).
+Our CI pipeline will automatically push the container images to [quay.io](https://quay.io/organization/prometheus-operator) and [ghcr.io](https://github.com/prometheus-operator/prometheus-operator/pkgs/container/prometheus-operator)
 
 Go to https://github.com/prometheus-operator/prometheus-operator/releases/new, associate the new release with the before pushed tag, paste in changes made to `CHANGELOG.md` and click "Publish release".
 
-For patch releases, submit a pull request to merge back the release branch into the `master` branch.
+For patch releases, submit a pull request to merge back the release branch into the `main` branch.
 
 ## Update website
 

contrib/kube-prometheus/README.md

@@ -28,7 +28,7 @@ Users depending on kube-prometheus with jsonnet-bundler, should change this thei
 +                    "subdir": "jsonnet/kube-prometheus"
                  }
              },
-             "version": "master"
+             "version": "main"
 ```
 
 *Note: We needed to merge the two repositories and commit hashes are not the same anymore, when referencing prometheus-operator/kube-prometheus.*

governance.md

@@ -7,7 +7,7 @@ It is meant to be followed by all the developers of the Prometheus Operator proj
 * **Maintainers Team**: A core Prometheus Operator team that have owner access to https://github.com/prometheus-operator organization and all projects within it. Current list is available [here](MAINTAINERS.md).
 
 * **Triage Team**: Contributors who does not belong to Maintainer's team, but has `Triage` GitHub role on [Prometheus Operator](https://github.com/prometheus-operator) repository allowing to change GitHub issues and PRs statuses and labels.
-  They are listed [here](https://github.com/prometheus-operator/prometheus-operator/blob/master/MAINTAINERS.md#triage).
+  They are listed [here](https://github.com/prometheus-operator/prometheus-operator/blob/main/MAINTAINERS.md#triage).
 
 * **The Prometheus Operator project**: The sum of all activities performed under the [prometheus-operator organization on GitHub](https://github.com/prometheus-operator), concerning one or more repositories or the community.
 
@@ -71,7 +71,7 @@ Upon death of a member, their Triage team membership ends automatically.
 ### Technical decisions
 
 Smaller technical decisions are made informally and [lazy consensus](#consensus) is assumed. Technical decisions that span multiple parts of the Prometheus Operator project
-should be discussed and made on the [GitHub issues](https://github.com/prometheus-operator/prometheus-operator/issues) and in most cases followed by proposal as described [here](https://github.com/prometheus-operator/prometheus-operator/blob/master/CONTRIBUTING.md).
+should be discussed and made on the [GitHub issues](https://github.com/prometheus-operator/prometheus-operator/issues) and in most cases followed by proposal as described [here](https://github.com/prometheus-operator/prometheus-operator/blob/main/CONTRIBUTING.md).
 
 Decisions are usually made by [lazy consensus](#consensus). If no consensus can be reached, the matter may be resolved by [majority vote](#majority-vote).
 
@@ -162,7 +162,7 @@ It's about number of up votes to agree on the decision.
 
 ### How do I propose a decision?
 
-See [Contributor doc](https://github.com/prometheus-operator/prometheus-operator/blob/master/CONTRIBUTING.md)
+See [Contributor doc](https://github.com/prometheus-operator/prometheus-operator/blob/main/CONTRIBUTING.md)
 
 ### How do I become a team member?
 

pkg/alertmanager/types.go

@@ -22,7 +22,7 @@ import (
 )
 
 // Customization of Config type from alertmanager repo:
-// https://github.com/prometheus/alertmanager/blob/master/config/config.go
+// https://github.com/prometheus/alertmanager/blob/main/config/config.go
 //
 // Custom global type to get around obfuscation of secret values when
 // marshalling. See the following issue for details:

pkg/apis/monitoring/v1/types.go

@@ -1410,7 +1410,7 @@ type PrometheusRuleSpec struct {
 // RuleGroup is a list of sequentially evaluated recording and alerting rules.
 // Note: PartialResponseStrategy is only used by ThanosRuler and will
 // be ignored by Prometheus instances.  Valid values for this field are 'warn'
-// or 'abort'.  More info: https://github.com/thanos-io/thanos/blob/master/docs/components/rule.md#partial-response
+// or 'abort'.  More info: https://github.com/thanos-io/thanos/blob/main/docs/components/rule.md#partial-response
 // +k8s:openapi-gen=true
 type RuleGroup struct {
 	Name                    string `json:"name"`

pkg/versionutil/doc.go

@@ -12,6 +12,6 @@
 // See the License for the specific language governing permissions and
 // limitations under the License.
 
-// Extends the https://github.com/prometheus/common/blob/master/version/info.go package by
+// Extends the https://github.com/prometheus/common/blob/main/version/info.go package by
 // adding common CLI support and test coverage.
 package versionutil

scripts/push-docker-image.sh

@@ -29,10 +29,10 @@ export TAG="${GITHUB_REF##*/}"
 # Push `-dev` images unless commit is tagged
 IMAGE_SUFFIX="-dev"
 
-# Use the main image repository if TAG is a semver tag or it is a master branch.
+# Use the main image repository if TAG is a semver tag or it is a main or master branch.
 # Otherwise assemble the image tag from VERSION file + short commit SHA and
 # push them to the dev image repository.
-if [[ "$TAG" =~ ^v[0-9]+\.[0-9]+ ]] || [ "${TAG}" == "master" ]; then
+if [[ "$TAG" =~ ^v[0-9]+\.[0-9]+ ]] || [ "${TAG}" == "master" ] || [ "${TAG}" == "main" ]; then
 	# Reset suffixes as images are not development ones
 	IMAGE_SUFFIX=""
 else