fix: outdated links in cocepts (#1644)

* fix: outdated links in quality_gates Signed-off-by: Rakshit Gondwal <[email protected]> * fix: all outdated links Signed-off-by: Rakshit Gondwal <[email protected]> --------- Signed-off-by: Rakshit Gondwal <[email protected]>
keptn · Jun 7, 2023 · 85f3fa3 · 85f3fa3
1 parent 3d2216c
commit 85f3fa3
Show file tree

Hide file tree

Showing 4 changed files with 23 additions and 23 deletions.
diff --git a/content/docs/concepts/architecture/index.md b/content/docs/concepts/architecture/index.md
@@ -20,8 +20,8 @@ NATS is used to communicate with the Execution Plane as discussed below.
 
 ## Keptn CLI
 
-Use the [Keptn CLI](../../0.19.x/reference/cli/) to send commands
-that interact with the [Keptn API](../../0.19.x/reference/api/).
+Use the [Keptn CLI](../../1.0.x/reference/cli/) to send commands
+that interact with the [Keptn API](../../1.0.x/reference/api/).
 It must be [installed](../../install/cli-install/)
 on the local machine and is used to send commands to Keptn.
 To communicate with Keptn, you need to know the API token (`keptn-api-token`),
@@ -32,7 +32,7 @@ which is created during the installation via Helm and verified by the *api* comp
 The *Keptn Bridge* is a user interface that can be used
 to view and manage Keptn projects and services.
 
-See [Keptn Bridge](../../0.19.x/bridge/),
+See [Keptn Bridge](../../1.0.x/bridge/),
 for information about how to access and use the Keptn Bridge.
 
 ## Keptn Control Plane
@@ -54,10 +54,10 @@ api, bridge, or resource-service.
 
 ### api-service
 
-The [Keptn API](../../0.19.x/reference/api/) provides a REST API
+The [Keptn API](../../1.0.x/reference/api/) provides a REST API
 that allows you to communicate with Keptn.
 It provides endpoints to authenticate, get metadata about the Keptn installation within the cluster,
-forward [CloudEvents](../../0.19.x/reference/miscellaneous/events/)
+forward [CloudEvents](../../1.0.x/reference/miscellaneous/events/)
 to the NATS cluster, and trigger evaluations for a service.
 
 ### mongodb-datastore
@@ -66,7 +66,7 @@ The *mongodb-datastore* stores event data in a MongoDB
 that, by default, is deployed in your Keptn namespace.
 You can instead use an externally hosted MongoDB by configuring
 the [connectionString](https://github.com/keptn/keptn/blob/539339ef3da8e55d7968852a88ed01e0088f5871/installer/manifests/keptn/values.yaml#L47) fields
-in the [values.yaml](../../0.19.x/reference/files/values/) file.
+in the [values.yaml](../../1.0.x/reference/files/values/) file.
 The service provides the REST endpoint `/events` to query events.
 The `mongodb-datastore` and `shipyard-controller` pods
 have direct connections to mongodb (`keptn-mongo`).
@@ -76,7 +76,7 @@ have direct connections to mongodb (`keptn-mongo`).
 The *resource-service* is a Keptn core component
 that manages resources for Keptn project-related entities, i.e., project, stage, and service.
 This replaces the `configuration-service` that was used in Keptn releases before 0.16.x.
-It uses the Git-based [upstream repository](../../0.19.x/manage/git_upstream/)
+It uses the Git-based [upstream repository](../../1.0.x/manage/git_upstream/)
 to store the resources with version control.
 This service can upload the Git repository to any Git-based service
 such as GitLab, GitHub, and Bitbucket.
@@ -90,7 +90,7 @@ Note that, in earlier releases, this file was mounted as a Persistent Volume Cla
 The *shipyard-controller* manages all Keptn-related entities, such as projects, stages and services,
 and provides an HTTP API that is used to perform CRUD operations on them. 
 This service also controls the execution of task sequences
-that are defined in the project's [shipyard](../../0.19.x/reference/files/shipyard/)
+that are defined in the project's [shipyard](../../1.0.x/reference/files/shipyard/)
 by sending out `.triggered` events whenever a task within a task sequence should be executed. 
 It then listens for incoming `.started` and `.finished` events
 and uses them to proceed with the task sequence.
@@ -111,7 +111,7 @@ Those services can be plugged into a task sequence
 to extend the delivery pipeline or to further automate operations.
 Execution plane services subscribe to events using one of the following mechanisms:
 
-* [distributor](../../0.19.x/reference/miscellaneous/distributor/) sidecar
+* [distributor](../../1.0.x/reference/miscellaneous/distributor/) sidecar
 that forwards incoming `.triggered` events to execution plane services.
 These distributor sidecars can also be used to send `.started` and `.finished` events
 back to the Keptn control plane.
@@ -137,7 +137,7 @@ The default Keptn installation includes Keptn-services for some Execution Plane
   If the approval strategy within a stage has been set to `manual`,
   the `approval-service` does not respond with any event since, in that case,
   the user is responsible for sending an `approval.finished` event
-  (using either the [Keptn Bridge](../../0.19.x/bridge/#approvals) or the API).  
+  (using either the [Keptn Bridge](../../1.0.x/bridge/#approvals) or the API).  
 
 - **remediation-service:** determines the action to be performed in remediation workflows. 
 
@@ -174,7 +174,7 @@ to communicate with the Execution Plane.
    but they can be configured to fetch open `.triggered` events from the HTTP API.
 
 See [Integrations](../../integrations/) for links to Keptn-service integrations that are available.
-Use the information in [Custom Integrations](../../0.19.x/integrations/)
+Use the information in [Custom Integrations](../../1.0.x/integrations/)
 to create a Keptn-service that integrates other tools.
 
 ### NATS behavior on a single-cluster instance
@@ -186,15 +186,15 @@ Execution plane service pods have a distributor container
 that subscribes to and publishes events on behalf of the execution plane service.
 
 Environment variables documented
-on the [distributor](../../0.19.x/reference/miscellaneous/distributor/) reference page
+on the [distributor](../../1.0.x/reference/miscellaneous/distributor/) reference page
 control how the distributor behaves,
 including setting the `PUBSUB_URL` environment variable that the distributor uses to locate the NATS cluster.
 
 The flow can be summarized as follows.
 Note that this discussion assumes using `helm-service` and tasks like `deployment`
 but another service could be used for this processing
 and any tool could listen for tasks with names other than those of the standard tasks
-that are documented on the [shipyard](../../0.19.x/reference/files/shipyard/#fields) reference page.
+that are documented on the [shipyard](../../1.0.x/reference/files/shipyard/#fields) reference page.
 
 1. The distributor for the execution plane services on a control plane
    handles the subscriptions and publishes operations for the execution plane service

diff --git a/content/docs/concepts/automated_operations/index.md b/content/docs/concepts/automated_operations/index.md
@@ -14,8 +14,8 @@ Keptn addresses this challenge by introducing the concept of micro-operations th
 Keptn complies with a declarative approach for configuring remediation and operations workflows as code on the level of individual microservices (rather than on applications). Consequently, this declaration is versioned next to the operational config and deployed with each new version of the microservice.
 
 Below is an example of a declarative `remediation.yaml` file as used in Keptn. The file defines two problem types and the respective remediation actions. In case of a response time degradation, new instances are scaled up and in the case of a failure rate increase, a feature is disabled.
-To learn more, see [Remediation Sequence](../../0.18.x/define/remediation-sequence/)
-and the [remediation](../../0.18.x/reference/files/remediation/) reference page. 
+To learn more, see [Remediation Sequence](../../1.0.x/define/remediation-sequence/)
+and the [remediation](../../1.0.x/reference/files/remediation/) reference page. 
 
 ```yaml
 version: 0.2.0
@@ -52,7 +52,7 @@ spec:
 
 In Keptn, a remediation action or operational task is implemented as micro-operation. Such a micro-operation is reduced to the max, meaning that it is designed to execute a single action. This action is implemented for a single microservice rather than an entire application. Consequently, declarative instructions procedures are written on a per-microservice basis, which you can select and combine as needed.
 
-A micro-operation is implemented by an [action-provider](../../0.18.x/integrations/custom_integration/), which is a Keptn-service with a dedicated purpose. This type of service is responsible for executing an action (aka. micro-operation) and therefore might even use another tool. An action-provider starts working, when receiving a Keptn CloudEvent of type: `sh.keptn.event.action.triggered`. To learn more about the implementation of a micro-operation by an action-provider, please continue [here](../../0.15.x/automated_operations/action-provider/). 
+A micro-operation is implemented by an [action-provider](../../1.0.x/integrations/custom_integration/), which is a Keptn-service with a dedicated purpose. This type of service is responsible for executing an action (aka. micro-operation) and therefore might even use another tool. An action-provider starts working, when receiving a Keptn CloudEvent of type: `sh.keptn.event.action.triggered`. To learn more about the implementation of a micro-operation by an action-provider, please continue [here](../../0.15.x/automated_operations/action-provider/). 
 
 ## Event-driven Choreography
 

diff --git a/content/docs/concepts/keptn-tools/index.md b/content/docs/concepts/keptn-tools/index.md
@@ -23,7 +23,7 @@ It allows for interoperability and any kinds of integrations in the Keptn ecosys
 
 ## Start with the shipyard
 
-Keptn's [shipyard](../../0.19.x/reference/files/shipyard/) file is the blueprint for your Keptn environment.
+Keptn's [shipyard](../../1.0.x/reference/files/shipyard/) file is the blueprint for your Keptn environment.
 While it may look like a pipeline, nowhere does it mention the tooling used to action each task.
 This is deliberate and by design.
 It is this factor that allows hot-swapping of tools.

diff --git a/content/docs/concepts/quality_gates/index.md b/content/docs/concepts/quality_gates/index.md
@@ -16,8 +16,8 @@ Keptn quality gates provide a *declarative way* to define quality criteria of yo
 Keptn quality gates are based on the concepts of *Service-Level Indicators (SLIs)* and *Service-Level Objectives (SLOs)*. Using these, you can declaratively describe the desired quality objective for your applications and services.
 
 1. The process of evaluating a quality gate can be triggered using
-the [Keptn Bridge](../../0.19.x/bridge/), the Keptn CLI or the Keptn API. 
-1. Once triggered, Keptn fetches the [SLIs](../../0.18.x/reference/files/sli/). 
+the [Keptn Bridge](../../1.0.x/bridge/), the Keptn CLI or the Keptn API. 
+1. Once triggered, Keptn fetches the [SLIs](../../1.0.x/reference/files/sli/). 
 from a data provider like Prometheus, Dynatrace, or Datadog.
 1. Keptn evaluates the SLI against the SLOs that are defined for the application or service. 
 1. After evaluation and scoring, Keptn returns the result that can be either processed in an automated way by an existing CD pipeline or by the user to manually decide on the next steps (e.g., promotion to production or pushing it back to the developer for needed improvements).
@@ -31,25 +31,25 @@ from a data provider like Prometheus, Dynatrace, or Datadog.
 
 A service-level indicator is a *"carefully defined quantitative measure of some aspect of the level of service that is provided"* (as defined in the [Site-Reliability Engineering Book](https://landing.google.com/sre/sre-book/chapters/service-level-objectives/)). 
 
-An example of an SLI is the *response time* (also named request latency), which is the indicator of how long it takes for a request to respond with an answer. Other prominent SLIs are *error rate* (or failure rate), and throughput. Keptn defines all SLIs in a dedicated [sli.yaml](../../0.18.x/reference/files/sli/)  file to make SLIs reusable within several quality gates.
+An example of an SLI is the *response time* (also named request latency), which is the indicator of how long it takes for a request to respond with an answer. Other prominent SLIs are *error rate* (or failure rate), and throughput. Keptn defines all SLIs in a dedicated [sli.yaml](../../1.0.x/reference/files/sli/)  file to make SLIs reusable within several quality gates.
 
 By default, SLIs are defined at the project level
 but they can also be defined for a specific stage or service within a stage.
-See the [SLI reference page](../../0.19.x/reference/files/sli/) for details.
+See the [SLI reference page](../../1.0.x/reference/files/sli/) for details.
 
 ## What is a Service-Level Objective (SLO)?
 
 A service-level objective is *"a target value or range of values for a service level that is measured by an SLI."* (as defined in the [Site-Reliability Engineering Book](https://landing.google.com/sre/sre-book/chapters/service-level-objectives/)). 
 
-An example of an SLO can define that a specific request must return results within 100 milliseconds. Keptn quality gates can comprise several SLOs that are all evaluated and scored, based even on different weights for each SLO to consider different importance of each SLO. Keptn defines SLOs in a dedicated [slo.yaml](../../0.18.x/reference/files/slo/) file.
+An example of an SLO can define that a specific request must return results within 100 milliseconds. Keptn quality gates can comprise several SLOs that are all evaluated and scored, based even on different weights for each SLO to consider different importance of each SLO. Keptn defines SLOs in a dedicated [slo.yaml](../../1.0.x/reference/files/slo/) file.
 
 
 ## Quality gate result on the Keptn Bridge
 
 :bulb: *A quality gate answers one question: Does my service meet all defined quality criteria?*
 
 Keptn quality gates help you answer this question by representing
-quality gate results on the [Keptn Bridge](../../0.18.x/bridge/) like this:
+quality gate results on the [Keptn Bridge](../../1.0.x/bridge/) like this:
 
 <!--TODO: Change image and add annotations [1] ... [5] -->