From bdf245e2d30fcc2137558535ffa4124eb3b9132e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6ren=20Henning?= <soeren.henning@email.uni-kiel.de>
Date: Fri, 15 Jul 2022 19:13:03 +0200
Subject: [PATCH] Complete renaming of master branch to main
---
.gitlab-ci.yml | 2 +-
docs/creating-a-benchmark.md | 2 +-
docs/development/release-process.md | 6 +++---
docs/installation.md | 4 ++--
docs/quickstart.md | 2 +-
docs/running-benchmarks.md | 2 +-
docs/theodolite-benchmarks/load-generator.md | 6 +++---
7 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 4e1a3b37b..c4d16ca78 100644
--- a/.gitlab-ci.yml
+++ b/.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
diff --git a/docs/creating-a-benchmark.md b/docs/creating-a-benchmark.md
index f27935ff9..9aba9a71a 100644
--- a/docs/creating-a-benchmark.md
+++ b/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
diff --git a/docs/development/release-process.md b/docs/development/release-process.md
index 21f913fbb..c7ef78ad6 100644
--- a/docs/development/release-process.md
+++ b/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.
diff --git a/docs/installation.md b/docs/installation.md
index a46caea3e..e03552701 100644
--- a/docs/installation.md
+++ b/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
diff --git a/docs/quickstart.md b/docs/quickstart.md
index 6effc0cb2..aa85fe7d9 100644
--- a/docs/quickstart.md
+++ b/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:
diff --git a/docs/running-benchmarks.md b/docs/running-benchmarks.md
index 8746bf17d..9d600a728 100644
--- a/docs/running-benchmarks.md
+++ b/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:
diff --git a/docs/theodolite-benchmarks/load-generator.md b/docs/theodolite-benchmarks/load-generator.md
index a41c97d52..e7d309355 100644
--- a/docs/theodolite-benchmarks/load-generator.md
+++ b/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()
--
GitLab