Fix links detected by the Daily Markdown Link Check

README.md

@@ -10,7 +10,7 @@ If you are looking for information on how to join us, you are in the right place
 
 ## Contribution rules
 
-Before you start contributing, read our [Code of Conduct](docs/contributing/01-code-of-conduct.md) and learn about our [working model](docs/governance/01-governance.md) to understand the way Kyma community works. Get familiar with the [contributing rules](docs/contributing/02-contributing.md), recommended [Git workflow](docs/contributing/03-git-workflow.md), [Prow workflow](docs/contributing/04-prow-workflow.md), and [issues workflow](docs/governance/03-issues-workflow.md) we use in Kyma so you can apply them later in practice as an active contributor.
+Before you start contributing, read our [Code of Conduct](docs/contributing/01-code-of-conduct.md) and learn about our [working model](docs/governance/01-governance.md) to understand the way Kyma community works. Get familiar with the [contributing rules](docs/contributing/02-contributing.md), recommended [Git workflow](docs/contributing/03-git-workflow.md), and [issues workflow](docs/governance/03-issues-workflow.md) we use in Kyma so you can apply them later in practice as an active contributor.
 
 ## Guidelines
 

concepts/installer-migration-hooks/README.md

@@ -233,7 +233,7 @@ hydroform
 - To have a consistent output, we will use the Unified Logging library. The logs should be sent back to the caller (aka CLI).
 
 ## Results after implementing Draft-PoC
-The pre-described PoC was implemented on [this branch](https://github.com/JeremyHarisch/hydroform/tree/jobManager), and tested using [this](https://github.com/kyma-project/kyma/pull/11132) as an [example pre-job](https://github.com/JeremyHarisch/hydroform/blob/jobManager/parallel-install/pkg/jobmanager/sampleJob.go) for the `logging` component.
+The pre-described PoC was implemented on [this branch](https://github.com/JeremyHarisch/hydroform/tree/jobManager), and tested using [this](https://github.com/kyma-project/kyma/pull/11132) as an example pre-job for the `logging` component.
 In the draft implementation, the Unified Logging Library was not used, but can be used in the final implementation.
 
 In general, it works in the way we want to, but with some tradeoffs. The mechanism was tested using a local k3d cluster, as well as on an Azure cluster provisioned by Gardener.

concepts/observability-strategy/configurable-logging/03-fluent-bit-operator1.md

@@ -123,7 +123,7 @@ kubectl get secret --namespace logging grafana -o jsonpath="{.data.admin-passwor
 ```bash
 kubectl -n logging port-forward svc/grafana 3000:80
 ```
-
+<!-- markdown-link-check-disable-next-line -->
 4. Open the Grafana Dashboard: http://localhost:3000 and log in. Select Menu > Explore, select Data source > Loki, then select Log labels > namespace > logging. A list of logs should appear.
 
 # Feature comparison matrix

docs/README.md

@@ -10,7 +10,7 @@ If you are looking for information on how to join us, you are in the right place
 
 ## Contribution rules
 
-Before you start contributing, read our [Code of Conduct](./contributing/01-code-of-conduct.md) and learn about our [working model](./governance/01-governance.md) to understand the way the Kyma community works. Get familiar with the [contributing rules](./contributing/02-contributing.md), recommended [Git workflow](./contributing/03-git-workflow.md), [Prow workflow](./contributing/04-prow-workflow.md), and [issues workflow](./governance/03-issues-workflow.md) we use in Kyma so you can apply them later in practice as an active contributor.
+Before you start contributing, read our [Code of Conduct](./contributing/01-code-of-conduct.md) and learn about our [working model](./governance/01-governance.md) to understand the way the Kyma community works. Get familiar with the [contributing rules](./contributing/02-contributing.md), recommended [Git workflow](./contributing/03-git-workflow.md), and [issues workflow](./governance/03-issues-workflow.md) we use in Kyma so you can apply them later in practice as an active contributor.
 
 ## Guidelines
 

docs/governance/01-governance.md

@@ -66,7 +66,7 @@ should request a change of their status to emeritus.
 
 ### How to suggest a change in a maintainers list?
 
-To suggest a change in the ownership of a given repository part, create a PR with the required changes in the `CODEOWNERS` file in the project's repository. The required number of codeowners needs to approve the PR for the changes to take place. Read the [CODEOWNERS  file template](https://github.com/kyma-project/community/blob/main/templates/repository-template/CODEOWNERS) to learn how to set up and modify owners of the given repository folders and files.
+To suggest a change in the ownership of a given repository part, create a PR with the required changes in the `CODEOWNERS` file in the project's repository. The required number of codeowners needs to approve the PR for the changes to take place. Read the [CODEOWNERS  file template](https://github.com/kyma-project/template-repository/blob/main/CODEOWNERS) to learn how to set up and modify owners of the given repository folders and files.
 
 The name of the removed maintainer is added to the [emeritus](https://github.com/kyma-project/community/blob/main/emeritus.md) file with a short message about what areas the person worked on.
 

docs/governance/03-issues-workflow.md

@@ -70,7 +70,7 @@ When the work is done, the issue is closed.
 
 ### Stale issues
 
-To keep the Kyma backlog clean, the bot monitors all repositories in the organization. It marks old, inactive issues with the `stale` (Hex: #E4E669) label and closes them after a given period of time. For configuration details, check the [sample file](https://github.com/kyma-project/kyma/blob/main/.github/stale.yml).
+To keep the Kyma backlog clean, the bot monitors all repositories in the organization. It marks old, inactive issues with the `stale` (Hex: #E4E669) label and closes them after a given period of time.
 
 Although the bot helps us to keep the backlog clean, we regularly monitor its activities to make sure it is not closing issues that are still valid and important for Kyma. The Kyma team reviews the issues in the [Kyma backlog](https://github.com/kyma-project/kyma/issues) and acts on the issues as follows:
 - Closed issues:

docs/guidelines/content-guidelines/06-links.md

@@ -28,8 +28,4 @@ To add a reference to a YAML, JSON, SVG, PNG, or JPG file located in the `assets
 
 ## Links in documentation toggles
 
-To link to a document in a documentation toggle, the toggle must start with the `<div tabs name="{toggle-name}">` tag and end with the `</div>` tag, where **name** is a distinctive ID used for linking. For more information, read a separate [Tabs & toggles](./05-tabs.md) document.
-
-## Links to the archived documentation
-
-Use absolute links to link to the [archived version of the website](https://kyma-project-old.netlify.app/docs/root/kyma). Only the 1.24 and 1.23 versions are available. To link to the older versions, use respective tag in [GitHub sources](https://github.com/kyma-project/kyma/tree/main/docs).
+To link to a document in a documentation toggle, the toggle must start with the `<div tabs name="{toggle-name}">` tag and end with the `</div>` tag, where **name** is a distinctive ID used for linking. For more information, read a separate [Tabs & toggles](./05-tabs-toggles.md) document.

docs/guidelines/content-guidelines/10-docs-preview.md

@@ -15,6 +15,7 @@ To install docsify-cli, run `npm i docsify-cli -g`.
 To preview content on the Kyma website, save your changes and run the local server.
 
 1. Run `docsify serve docs` in the `/kyma` repository.
+<!-- markdown-link-check-disable-next-line -->
 2. Preview `https://kyma-project.io` in your browser on http://localhost:3000.
 
 ## Preview module documentation
@@ -38,4 +39,5 @@ To preview content on the Kyma website, save your changes and run the local serv
 
 3. Save your changes.
 4. Run `docsify serve docs`.
+<!-- markdown-link-check-disable-next-line -->
 5. Preview `https://kyma-project.io` in your browser on http://localhost:3000.

docs/guidelines/releases-guidelines/01-release-strategy.md

@@ -126,7 +126,7 @@ After reaching the end of the development cycle, the Kyma developers create a re
 - two working days for minor releases
 - one week for major releases
 
-All release candidates must always be fully tested by all defined automated and manual tests, following the [test strategy](../technical-guidelines/07-test-strategy.md). Manual tests are tracked in [this sheet](https://docs.google.com/spreadsheets/d/1ty3OciQzgzv0GagTG2Dku9os2AfMupbGNf8QxjHaO88/edit) for each release candidate.
+All release candidates must always be fully tested by all defined automated and manual tests, following the [test strategy](../technical-guidelines/07-test-strategy.md).
 
 During the release process, only [critical issues](#critical-issues) will be considered for cherry-picking. The Release Manager approves the final release to be prepared and published only when all tests have passed, and no critical issues are blocking the release.
 

docs/guidelines/releases-guidelines/02-kyma-release-process.md

@@ -93,15 +93,16 @@ Follow these steps to release another Kyma version. Execute these steps for ever
 
 1. Once the preparation for the release is finished, trigger the [Release Kyma](https://github.com/kyma-project/kyma/actions/workflows/github-release.yaml) GitHub action. 
    Choose the branch that corresponds to the release that you want to trigger. The exact release version is taken from the `VERSION` file.
-   When you click the **Run workflow** button, the release process waits for the approval from reviewers. 
-   The reviewers list is defined in the ["release" Github Environment](https://github.com/kyma-project/kyma/settings/environments). 
+   When you click the **Run workflow** button, the release process waits for the approval from reviewers.
+   <!-- markdown-link-check-disable-next-line -->
+   The reviewers list is defined in the ["release" Github Environment](https://github.com/kyma-project/kyma/settings/environments).
    After it is approved, the following will happen:
    * GitHub release is triggered.
    * Documentation update on the official Kyma website is triggered.
    * New release cluster is created for the given Kyma `RELEASE_VERSION`.
      If you don't have access to the GCP project, post a request in the Slack team channel.
      > **CAUTION**: The cluster is automatically generated for you, and it is automatically removed after 7 days.
-
+<!-- markdown-link-check-disable-next-line -->
 2. The Github release post-submit job creates a release in the `kyma-project/kyma` repository, which triggers the [`post-rel{RELEASE_VERSION_SHORT}-kyma-release-upgrade`](https://github.com/kyma-project/test-infra/blob/main/prow/jobs/kyma/kyma-release-upgrade.yaml) pipeline. The purpose of this job is to test upgradability between the latest Kyma release that is not a release candidate and the brand new release published by the release post-submit job.
     For example, if `1.7.0-rc2` is released, the pipeline will try to upgrade `1.6.0` to `1.7.0-rc2`.
 

docs/guidelines/releases-guidelines/03-kyma-cli-release-process.md

@@ -64,7 +64,7 @@ A Kyma CLI release consists of:
       If it's not due to bugs, simply close your PR and re-run the previous `brew bump-formula-pr` command with `--force` mode.
         - If you got the message `fatal: a branch named 'bump-kyma-cli-{RELEASE_VERSION}' already exists`, delete this local branch.
         - If you got the message `Error: You need to bump this formula manually since the new URL and old URL are both: https://github.com/kyma-project/cli/archive/{RELEASE_VERSION}.tar.gz`, restore the change in you local repo. The local repo is under `/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core`(Intel) or `/opt/homebrew/Library/Taps/homebrew/homebrew-core`(Apple Silicon).
-    - Alternatively, create a PR to the [kyma-cli Homebrew formula](https://github.com/Homebrew/homebrew-core/blob/master/Formula/kyma-cli.rb).
+    - Alternatively, create a PR to the [kyma-cli Homebrew formula](https://github.com/Homebrew/homebrew-core/blob/master/Formula/k/kyma-cli.rb).
 
     When a Homebrew maintainer approves your PR, the formula is updated.
 

docs/guidelines/releases-guidelines/07-release-subscription.md

@@ -5,4 +5,4 @@ label: internal
 
 GitHub offers an option to subscribe to email notifications on new releases in repositories. To learn how to watch the given repository only for the releases, read the [GitHub article](https://help.github.com/articles/watching-and-unwatching-releases-for-a-repository/).
 
-Alternatively, use free online tools, such as [CodeRelease.io](https://coderelease.io/), [GitPunch](https://gitpunch.com/), or [releases](https://releases.netlify.com/), to get e-mail notifications when the GitHub projects release a new version in the GitHub repositories that you watched and starred.
+Alternatively, use free online tools, such as [GitPunch](https://gitpunch.com/), or [releases](https://releases.netlify.com/), to get e-mail notifications when the GitHub projects release a new version in the GitHub repositories that you watched and starred.

docs/guidelines/repository-guidelines/01-new-repository-settings.md

@@ -35,22 +35,18 @@ To see these settings, go to **Branches** in the left menu, under repository **S
 
 ![Branch protection rules](./assets/branch-protection-rules.png)
 
-In Kyma, the protection rules are defined in the Prow [`config.yaml`](https://github.com/kyma-project/test-infra/blob/main/prow/config.yaml) file generated from rules defined in the [`prow-config.yaml`](https://github.com/kyma-project/test-infra/blob/main/templates/templates/prow-config.yaml) file and handled by a Prow component called [Branch Protector](https://github.com/kyma-project/test-infra/blob/main/docs/prow/prow-architecture.md#branch-protector).
+In Kyma, the protection rules are defined in the Prow [`config.yaml`](https://github.com/kyma-project/test-infra/blob/main/prow/config.yaml) file handled by a Prow component called [Branch Protector](https://github.com/kyma-project/test-infra/blob/main/docs/prow/prow-architecture.md#branch-protector).
 
 If you add a new repository in:
 - `kyma-project`, you do not need to add a new entry to the Prow `config.yaml` file as the branch protection is already defined for [all repositories](https://github.com/kyma-project/test-infra/blob/main/prow/config.yaml#L380) within this organization. The only exception is if you want to specify additional rules that are not handled by Prow.
-- `kyma-incubator`, add a new repository entry to the Prow `config.yaml` file, under **branch-protection.orgs.kyma-incubator.repos**. See [an example](https://github.com/kyma-project/test-infra/blob/main/templates/templates/prow-config.yaml)  of such an entry for the `marketplaces` repository.
+- `kyma-incubator`, add a new repository entry to the Prow `config.yaml` file, under **branch-protection.orgs.kyma-incubator.repos**.
 
 ## Update CLA assistant configuration
 
 Ask a [kyma-project owner](https://github.com/orgs/kyma-project/people) to:
 - Add the newly created repository to the [Contributor License Agreement](https://cla-assistant.io/) (CLA).
 - Add the `kyma-bot` username to be exempt from signing the CLA.
 
-## Add a milv file
-
-If you define any governance-related [Prow job](https://github.com/kyma-project/test-infra/blob/main/prow/jobs/) for the new repository to validate documentation links, you must add a `milv.config.yaml` file at the root of the repository. [See](https://github.com/kyma-project/test-infra/blob/main/milv.config.yaml) an example of the milv file.
-
 ## Custom settings
 
 Track all repository changes that deviate from configuration standard described in the guidelines with an [issue](https://github.tools.sap/kyma/test-infra/issues/new?assignees=&labels=config-change&template=bug_report.md&title=).

sigs-and-wgs/archive/sig-core/decisions/README.md

@@ -4,4 +4,4 @@
 
 This directory contains records of decisions made by the Core SIG and the Kyma project members before end of May 2019.
 
-Currently, decisions are made based on issues or pull requests that have the decision flag assigned. The decision-making process is described [here](https://github.com/kyma-project/community/blob/main/governance.md).
+Currently, decisions are made based on issues or pull requests that have the decision flag assigned. The decision-making process is described [here](https://github.com/kyma-project/community/blob/main/docs/governance/01-governance.md#decision-making).

sigs-and-wgs/archive/sig-core/decisions/dr-008-Dex_as_an_OIDC_authenticator.md

@@ -43,4 +43,4 @@ Although some of the Kyma team's pull requests were rejected, the team contribut
 After some discussion, the team managed to introduce [this](https://github.com/coreos/dex/issues/1087) change.
 
 Finally, Dex is designed to work with Kubernetes and is also one of the authentication solutions
-recommended in the [Kubernetes documentation](https://kubernetes.io/docs/admin/authentication/#configuring-the-api-server).
+recommended in the [Kubernetes documentation](https://kubernetes.io/docs).

sigs-and-wgs/archive/sig-core/decisions/dr-015-Authorization_for_GraphQL.md

@@ -19,7 +19,7 @@ Istio Ingress can then expose GraphQL and developers can define appropriate auth
 In the current release (0.7.x), **Istio RBAC engine** is implemented as a Mixer adapter.
 The **Request Context** sent to the **Istio RBAC engine** is provided as an instance of the **Authorization Template**.
 Information defined in the **Authorization Template** is fetched from [Istio Attributes](https://istio.io/docs/concepts/policy-and-control/attributes.html).
-A given Istio deployment has a [fixed vocabulary of attributes that it understands](https://istio.io/docs/reference/config/mixer/attribute-vocabulary.html).
+A given Istio deployment has a [fixed vocabulary of attributes that it understands](https://istio.io/v1.0/docs/concepts/policies-and-telemetry/#attribute-vocabulary).
 
 A set of **Service Roles** defines the authorization for a service in Istio.
 A **Service Role** specification includes a list of **Access Rules**.

sigs-and-wgs/archive/sig-core/decisions/dr-021-Remove-k8s-api-server-proxies.md

@@ -10,7 +10,7 @@ Created on 2021-07-12 by Piotr Bochyński (@pbochynski).
 | Due date | 2021-07-19 |
 | Status | Proposed on 2021-07-12, Accepted on 2021-08-04|
 | Decision type | Binary |
-| Affected decisions | [DR 007: GraphQL as API facade for UI](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/decisions/dr-007-GraphQL_as_API_facade_for_UI.md), [DR 015: Authorization for GraphQL](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/decisions/dr-015-Authorization_for_GraphQL.md), [DR 008: DEX as an OIDC authenticator](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/decisions/dr-008-Dex_as_an_OIDC_authenticator.md) |
+| Affected decisions | [DR 007: GraphQL as API facade for UI](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/decisions/dr-007-GraphQL_as_API_facade_for_UI.md), [DR 015: Authorization for GraphQL](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/decisions/dr-015-Authorization_for_GraphQL.md), [DR 008: DEX as an OIDC authenticator](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/decisions/dr-008-Dex_as_an_OIDC_authenticator.md) |
 
 ## Context
 
@@ -42,6 +42,6 @@ The benefits:
 - faster development and easier maintenance of the Console UI.
 
 As a result of this decision, the following decisions are invalid:
-- [DR 007: GraphQL as API facade for UI](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/decisions/dr-007-GraphQL_as_API_facade_for_UI.md)
-- [DR 015: Authorization for GraphQL](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/decisions/dr-015-Authorization_for_GraphQL.md)
-- [DR 008: DEX as an OIDC authenticator](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/decisions/dr-008-Dex_as_an_OIDC_authenticator.md)
+- [DR 007: GraphQL as API facade for UI](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/decisions/dr-007-GraphQL_as_API_facade_for_UI.md)
+- [DR 015: Authorization for GraphQL](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/decisions/dr-015-Authorization_for_GraphQL.md)
+- [DR 008: DEX as an OIDC authenticator](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/decisions/dr-008-Dex_as_an_OIDC_authenticator.md)