Complete renaming of master branch to main

.gitlab-ci.yml

@@ -42,7 +42,7 @@ default:
         KANIKO_D="$KANIKO_D -d $CR_HOST/$CR_ORG/$IMAGE_NAME:$CI_COMMIT_TAG"
         export PUBLISHED_IMAGE_TAG=$CI_COMMIT_TAG
       else
-        DOCKER_TAG_NAME=$(echo $CI_COMMIT_REF_SLUG- | sed 's/^master-$//')
+        DOCKER_TAG_NAME=$(echo $CI_COMMIT_REF_SLUG- | sed 's/^main-$//')
         KANIKO_D="$KANIKO_D -d $CR_HOST/$CR_ORG/$IMAGE_NAME:${DOCKER_TAG_NAME}latest"
         KANIKO_D="$KANIKO_D -d $CR_HOST/$CR_ORG/$IMAGE_NAME:$DOCKER_TAG_NAME$CI_COMMIT_SHORT_SHA"
         export PUBLISHED_IMAGE_TAG=$DOCKER_TAG_NAME$CI_COMMIT_SHORT_SHA

docs/creating-a-benchmark.md

@@ -191,7 +191,7 @@ A good choice to get started is defining an SLO of type `generic`:
 All you have to do is to define a [PromQL query](https://prometheus.io/docs/prometheus/latest/querying/basics/) describing which metrics should be requested (`promQLQuery`) and how the resulting time series should be evaluated. With `queryAggregation` you specify how the resulting time series is aggregated to a single value and `repetitionAggregation` describes how the results of multiple repetitions are aggregated. Possible values are
 `mean`, `median`, `mode`, `sum`, `count`, `max`, `min`, `std`, `var`, `skew`, `kurt` as well as percentiles such as `p99` or `p99.9`. The result of aggregation all repetitions is checked against `threshold`. This check is performed using an `operator`, which describes that the result must be "less than" (`lt`), "less than equal" (`lte`), "greater than" (`gt`) or "greater than equal" (`gte`) to the threshold.
 
-In case you need to evaluate monitoring data in a more flexible fashion, you can also change the value of `externalSloUrl` to your custom SLO checker. Have a look at the source code of the [generic SLO checker](https://github.com/cau-se/theodolite/tree/master/slo-checker/generic) to get started.
+In case you need to evaluate monitoring data in a more flexible fashion, you can also change the value of `externalSloUrl` to your custom SLO checker. Have a look at the source code of the [generic SLO checker](https://github.com/cau-se/theodolite/tree/main/slo-checker/generic) to get started.
 
 ## Kafka Configuration
 

docs/development/release-process.md

@@ -13,7 +13,7 @@ We assume that we are creating the release `v0.3.1`. Please make sure to adjust
 the following steps according to the release, you are actually performing.
 
 1. Create a new branch `v0.3` if it does not already exist. This branch will never
-again be merged into master.
+again be merged into main.
 
 2. Checkout the `v0.3` branch.
 
@@ -43,7 +43,7 @@ again be merged into master.
 
 8. Create *releases* on GitLab and GitHub. Upload the generated Helm package to these releases via the UIs of GitLab and GitHub.
 
-9. Switch to the `master` branch.
+9. Switch to the `main` branch.
 
 10. Re-run `./update-index.sh v0.3.1` to include the latest release in the *upstream* Helm repository. You can now delete the packaged Helm chart.
 
@@ -57,4 +57,4 @@ again be merged into master.
 
     4. Update the `CITATION.cff` file according to Step 3.
 
-12. Commit these changes to the `master` branch.
+12. Commit these changes to the `main` branch.

docs/installation.md

@@ -26,11 +26,11 @@ As usual, the installation via Helm can be configured by passing a values YAML f
 helm install theodolite theodolite/theodolite --values <your-config.yaml>
 ```
 
-For this purpose the [default values file](https://github.com/cau-se/theodolite/blob/master/helm/values.yaml) can serve as a template for your custom configuration.
+For this purpose the [default values file](https://github.com/cau-se/theodolite/blob/main/helm/values.yaml) can serve as a template for your custom configuration.
 
 ### Minimal setup
 
-For Kubernetes clusters with limited resources such as on local developer installations, we provide a [minimal values file](https://github.com/cau-se/theodolite/blob/master/helm/preconfigs/minimal.yaml).
+For Kubernetes clusters with limited resources such as on local developer installations, we provide a [minimal values file](https://github.com/cau-se/theodolite/blob/main/helm/preconfigs/minimal.yaml).
 
 ### Persisting results
 

docs/quickstart.md

@@ -15,7 +15,7 @@ All you need to get started is access to a Kubernetes cluster plus kubectl and H
     ```sh
     helm repo add theodolite https://cau-se.github.io/theodolite
     helm repo update
-    helm install theodolite theodolite/theodolite -f https://raw.githubusercontent.com/cau-se/theodolite/master/helm/preconfigs/minimal.yaml
+    helm install theodolite theodolite/theodolite -f https://raw.githubusercontent.com/cau-se/theodolite/main/helm/preconfigs/minimal.yaml
     ```
 
 1. Get the Theodolite examples from the [Theodolite repository](https://github.com/cau-se/theodolite) and `cd` into its example directory:

docs/running-benchmarks.md

@@ -134,7 +134,7 @@ The easiest way to use them is at MyBinder:
 [Launch Notebooks](https://mybinder.org/v2/gh/cau-se/theodolite/HEAD?labpath=analysis){: .btn .btn-primary }
 {: .text-center }
 
-Alternatively, you can also [run these notebook locally](https://github.com/cau-se/theodolite/tree/master/analysis), for example, with Docker or Visual Studio Code.
+Alternatively, you can also [run these notebook locally](https://github.com/cau-se/theodolite/tree/main/analysis), for example, with Docker or Visual Studio Code.
 
 The notebooks allow to compute a scalability function using Theodolite's *demand* metric and to visualize multiple such functions in plots:
 

docs/theodolite-benchmarks/load-generator.md

@@ -22,7 +22,7 @@ docker run -it ghcr.io/cau-se/theodolite-uc1-workload-generator
 
 ### Message format
 
-Messages generated by the load generators represent a single measurement of [active power](https://en.wikipedia.org/wiki/AC_power#Active,_reactive,_apparent,_and_complex_power_in_sinusoidal_steady-state). The corresponding message type is specified as [`ActivePowerRecords`](https://github.com/cau-se/titan-ccp-common/blob/master/src/main/avro/ActivePower.avdl)
+Messages generated by the load generators represent a single measurement of [active power](https://en.wikipedia.org/wiki/AC_power#Active,_reactive,_apparent,_and_complex_power_in_sinusoidal_steady-state). The corresponding message type is specified as [`ActivePowerRecords`](https://github.com/cau-se/titan-ccp-common/blob/main/src/main/avro/ActivePower.avdl)
 defined with Avro. It consists of an identifier for simulated power sensor, a timestamp in epoch milliseconds and the actual measured (simulated) value in watts.
 
 When sending generated records via Apache Kafka, these records are serialized with the [Confluent Schema Registry](https://docs.confluent.io/platform/current/schema-registry).
@@ -66,11 +66,11 @@ The prebuilt container images can be configured with the following environment v
 | `THREADS` | Number of worker threads used to generate the load. | 4 |
 | `DISABLE_DNS_CACHING` | Set to `true` to disable DNS caching by the underlying JVM. You might want to do so when generating load via HTTP that should be sent to different target instances. | `false` |
 
-Please note that there are some additional configuration options for benchmark [UC4's load generator](hhttps://github.com/cau-se/theodolite/blob/master/theodolite-benchmarks/uc4-load-generator/src/main/java/rocks/theodolite/benchmarks/uc4/loadgenerator/LoadGenerator.java).
+Please note that there are some additional configuration options for benchmark [UC4's load generator](hhttps://github.com/cau-se/theodolite/blob/main/theodolite-benchmarks/uc4-load-generator/src/main/java/rocks/theodolite/benchmarks/uc4/loadgenerator/LoadGenerator.java).
 
 ## Creating a custom load generator
 
-To create a custom load generator, you need to import the [load-generator-commons](https://github.com/cau-se/theodolite/tree/master/theodolite-benchmarks/load-generator-commons) project. You can then create an instance of the `LoadGenerator` populated with a default configuration, adjust it as desired, and start it by calling its `run` method:
+To create a custom load generator, you need to import the [load-generator-commons](https://github.com/cau-se/theodolite/tree/main/theodolite-benchmarks/load-generator-commons) project. You can then create an instance of the `LoadGenerator` populated with a default configuration, adjust it as desired, and start it by calling its `run` method:
 
 ```java
 LoadGenerator loadGenerator = new LoadGenerator.fromDefaults()