diff --git a/.github/workflows/deploy.yaml b/.github/workflows/deploy.yaml index a734c0e148..8f88560ffa 100644 --- a/.github/workflows/deploy.yaml +++ b/.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 diff --git a/.github/workflows/pullrequest.yaml b/.github/workflows/pullrequest.yaml new file mode 100644 index 0000000000..9e7dd49a2b --- /dev/null +++ b/.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 + diff --git a/_typos.toml b/_typos.toml new file mode 100644 index 0000000000..51712b4dd8 --- /dev/null +++ b/_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"] \ No newline at end of file diff --git a/docs/src/development/contributing.md b/docs/src/development/contributing.md index 3e44fd77c3..7148c5b2e6 100644 --- a/docs/src/development/contributing.md +++ b/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 diff --git a/docs/src/development/proposals/MEP1/README.md b/docs/src/development/proposals/MEP1/README.md index cdf16e9db8..4605203e2c 100644 --- a/docs/src/development/proposals/MEP1/README.md +++ b/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. diff --git a/docs/src/development/proposals/MEP8/README.md b/docs/src/development/proposals/MEP8/README.md index 265554cf0a..c9e3412e94 100644 --- a/docs/src/development/proposals/MEP8/README.md +++ b/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 diff --git a/docs/src/installation/troubleshoot.md b/docs/src/installation/troubleshoot.md index 6a68ed2d48..27e41e8e42 100644 --- a/docs/src/installation/troubleshoot.md +++ b/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 ` 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 --force`. +If, apart from that, the migration was successful, then the old switch can be safely deleted with `metalctl switch delete --force`. #### Preconditions for Migration and Replacement