[Misc] website: update website build + links in docu

- use latest version
- attempt to fix by updating links to remove {{ref}}

.github/workflows/publish-website.yaml

@@ -40,7 +40,7 @@ jobs:
       - name: Setup Hugo
         uses: peaceiris/actions-hugo@v3
         with:
-          hugo-version: "0.131.0"
+          hugo-version: "0.133.0"
           extended: true
       - name: Setup Node
         uses: actions/setup-node@v4

website/content/en/docs/concepts/_index.md

@@ -7,7 +7,7 @@ description: >
   Motivation and overview of components
 ---
 
-Provisioning and operating an SAP Cloud Application Programming Model application on a Kubernetes cluster requires the deployment of various components in addition to the CAP application server (see [a list of typical components]({{< ref "/cap-application-components.md" >}})). Some of these components can be created at the time of system provisioning, while others need to be created (or updated) at different points during the lifecycle of the application (DAY 2 operational tasks).
+Provisioning and operating an SAP Cloud Application Programming Model application on a Kubernetes cluster requires the deployment of various components in addition to the CAP application server (see [a list of typical components](./cap-application-components.md)). Some of these components can be created at the time of system provisioning, while others need to be created (or updated) at different points during the lifecycle of the application (DAY 2 operational tasks).
 
 Using Helm charts to manage the deployment of a CAP application can support the initial system provisioning, but further lifecycle operations (such as tenant provisioning) that are initiated from external components (SAP BTP) require manual adjustment of the deployed resources. An example of such an instance would be the creation of `VirtualServices` (part of Istio service mesh) during tenant provisioning to route application (HTTP) requests submitted on the new tenant subdomain to the application server. Another limitation of using helm charts is the lack of control over the order in which resources are created.
 

website/content/en/docs/usage/deploying-application.md

@@ -124,6 +124,6 @@ The controller component of CAP Operator reacts to these objects and creates fur
 
 > The content deployer is used to deploy content or configuration to SAP BTP services, before using them.
 
-Once these resources are available, the `CAPApplicationVersion` status changes to `Ready`. **The controller proceeds to automatically create an object of type `CAPTenant`, which corresponds to the tenant of the provider subaccount.** Please see [tenant subscription]({{< ref "/tenant-provisioning.md" >}}) for details on how the `CAPTenant` resource is reconciled.
+Once these resources are available, the `CAPApplicationVersion` status changes to `Ready`. **The controller proceeds to automatically create an object of type `CAPTenant`, which corresponds to the tenant of the provider subaccount.** Please see [tenant subscription](./tenant-provisioning.md) for details on how the `CAPTenant` resource is reconciled.
 
 > The `CAPApplicationVersion` resource is meant to be immutable - it's spec should not be modified once it is deployed. This is also prevented by our web-hooks which we recommend to always keep active (default).

website/content/en/docs/usage/version-upgrade.md

@@ -8,7 +8,7 @@ description: >
 ---
 
 An important lifecycle aspect of operating multi-tenant CAP applications is the tenant upgrade process. With CAP Operator, these tenant upgrades can be fully automated by providing a new instance of the `capapplicationversions.sme.sap.com` custom resource.
-As you've already seen during the [initial deployment]({{< ref "/deploying-application.md" >}}), the `CAPApplicationVersion` resource describes the different components (workloads) of an application version that includes the container image to be used and the services consumed by each component.
+As you've already seen during the [initial deployment](./deploying-application.md), the `CAPApplicationVersion` resource describes the different components (workloads) of an application version that includes the container image to be used and the services consumed by each component.
 To upgrade the application, provide a new `CAPApplicationVersion` with the relevant `image` for each component and use a newer (higher) semantic version in the `version` field. See [API Reference](../../reference/#sme.sap.com/v1alpha1.CAPApplicationVersion).
 
 ```yaml
@@ -90,7 +90,7 @@ spec:
         continueOnFailure: true
 ```
 
-Note that in this version (compared to version "1" used for the [initial deployment]({{< ref "/deploying-application.md" >}})), new workloads of type `TenantOperation` and `CustomTenantOperation` have been added.
+Note that in this version (compared to version "1" used for the [initial deployment](./deploying-application.md)), new workloads of type `TenantOperation` and `CustomTenantOperation` have been added.
 
 The controller component of CAP Operator reacts to the new `CAPApplicationVersion` resource and triggers another deployment for the application server, router and triggers the content deployment job. Once the new `CAPApplicationVersion` is `Ready`, **the controller proceeds to automatically upgrade all relevant tenants** i.e. by updating the `version` attribute on the `CAPTenant` resources.
 

website/package.json

@@ -1,7 +1,7 @@
 {
   "devDependencies": {
     "autoprefixer": "^10.4.20",
-    "hugo-extended": "^0.131.0",
+    "hugo-extended": "^0.132.2",
     "postcss-cli": "^11.0.0"
   }
 }