Check typos on prs (#220)

.github/workflows/deploy.yaml

@@ -15,6 +15,10 @@ jobs:
         with:
           submodules: "true"
           lfs: true
+
+      - name: Check spelling
+        uses: crate-ci/typos@master
+
       - uses: julia-actions/setup-julia@latest
         with:
           version: 1.9.4

.github/workflows/pullrequest.yaml

@@ -0,0 +1,15 @@
+---
+name: Release drafter
+
+on:
+  pull_request:
+    branches:
+      - master
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+

_typos.toml

@@ -0,0 +1,8 @@
+[default.extend-words]
+# Don't correct the surname "Teh"
+CLOS = "CLOS"
+leafs = "leafs"
+nd = "nd"
+
+[files]
+extend-exclude = ["*.svg", "*.drawio", "allocate.yml"]

docs/src/development/contributing.md

@@ -40,7 +40,7 @@ This section contains language-agnostic topics that all metal-stack projects are
 
 The code base is owned by the entire team and every member is allowed to contribute changes to any of the projects. This is considered as collective code ownership[^1].
 
-As a matter of fact, there are persons in a project, which already have experience with the sources. These are defined directly in the repository's [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) file. If you want to merge changes into the master branch, it is advisable to include code owners into the proecess of discussion and merging.
+As a matter of fact, there are persons in a project, which already have experience with the sources. These are defined directly in the repository's [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) file. If you want to merge changes into the master branch, it is advisable to include code owners into the process of discussion and merging.
 
 ### Microservices
 

docs/src/development/proposals/MEP1/README.md

@@ -82,7 +82,7 @@ In order to replicate certain data which must be available across all partitions
   Postgres does not have a multi datacenter with replication in both directions, it just can make the remote instance store the same data.
 - CockroachDB
 
-  Is a Postgresql compatible database enginge on the wire. CockroachDB gives you both, ACID and geo replication with writes allowed from all connected members. It is even possible to configure [Follow the Workload](https://www.cockroachlabs.com/docs/stable/topology-follow-the-workload) and [Geo Partitioning and Replication](https://www.cockroachlabs.com/docs/v19.2/topology-geo-partitioned-replicas).
+  Is a Postgresql compatible database engine on the wire. CockroachDB gives you both, ACID and geo replication with writes allowed from all connected members. It is even possible to configure [Follow the Workload](https://www.cockroachlabs.com/docs/stable/topology-follow-the-workload) and [Geo Partitioning and Replication](https://www.cockroachlabs.com/docs/v19.2/topology-geo-partitioned-replicas).
 
 If we migrate all metal-api entities to be stored the same way we store masterdata, we could use cockroachdb to store all metal entities in one ore more databases spread across all partitions and still ensure consistency and high availability.
 

docs/src/development/proposals/MEP8/README.md

@@ -116,8 +116,8 @@ type Disk struct {
 // Raid is optional, if given the devices must match.
 // TODO inherit GPTType from underlay device ?
 type Raid struct {
-  // ArryName of the raid device, most often this will be /dev/md0 and so forth
-  ArryName    string
+  // ArrayName of the raid device, most often this will be /dev/md0 and so forth
+  ArrayName    string
   // Devices the devices to form a raid device
   Devices []Device
   // Level the raidlevel to use, can be one of 0,1,5,10 

docs/src/installation/troubleshoot.md

@@ -246,7 +246,7 @@ If the new switch should have the same ID as the old one you should perform a sw
 To find detailed information about the procedure of a switch replacement use `metalctl switch replace --help`.
 Basically, what you need to do is mark the switch for replacement via `metalctl switch replace`, then physically replace the switch with the new one and configure it.
 The last step is to deploy metal-core on the switch.
-Once metal-core registers the new switch at the metal-api, the old switches configuration and machine connections will be transfered to the new one.
+Once metal-core registers the new switch at the metal-api, the old switches configuration and machine connections will be transferred to the new one.
 Note that the replacement only works if the new switch has the same ID as the old one.
 Otherwise metal-core will simply register a new switch and leave the old one untouched.
 
@@ -268,7 +268,7 @@ The metal-api will think that a machine is connected to three switches.
 This, however, should not cause any problems.
 Just move on to step 6 and delete the old switch from the metal-api afterwards.
 If the case just described really occurs, then `metalctl switch delete <old-switch-id>` will throw an error, because deleting a switch with existing machine connections might be dangerous.
-If, apart from that, the migration was successfull, then the old switch can be safely deleted with `metalctl switch delete <old-switch-id> --force`.
+If, apart from that, the migration was successful, then the old switch can be safely deleted with `metalctl switch delete <old-switch-id> --force`.
 
 #### Preconditions for Migration and Replacement