From 0ca126ff2351022760ab3e1302c1d2290209d0b4 Mon Sep 17 00:00:00 2001 From: mbecker20 Date: Sun, 17 Aug 2025 18:21:01 -0700 Subject: [PATCH] fix broken docs links before publish --- docsite/docs/ecosystem/api.md | 2 +- docsite/docs/intro.md | 2 +- docsite/docs/resources/index.md | 2 +- docsite/docs/resources/permissioning.md | 2 +- docsite/docs/resources/variables.md | 2 +- docsite/docs/setup/backup.md | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docsite/docs/ecosystem/api.md b/docsite/docs/ecosystem/api.md index 290c38042..bc75e67a6 100644 --- a/docsite/docs/ecosystem/api.md +++ b/docsite/docs/ecosystem/api.md @@ -2,7 +2,7 @@ Komodo Core exposes an RPC-like HTTP API to read data, write configuration, and execute actions. There are typesafe clients available in -[**Rust**](/docs/api#rust-client) and [**Typescript**](/docs/api#typescript-client). +[**Rust**](/docs/ecosystem/api#rust-client) and [**Typescript**](/docs/ecosystem/api#typescript-client). The full API documentation is [**available here**](https://docs.rs/komodo_client/latest/komodo_client/api/index.html). diff --git a/docsite/docs/intro.md b/docsite/docs/intro.md index 726c2026e..c333ed64f 100644 --- a/docsite/docs/intro.md +++ b/docsite/docs/intro.md @@ -43,6 +43,6 @@ Komodo exposes powerful functionality over the Core's REST and Websocket API, en ## Permissioning -Komodo is a system designed to be used by many users, whether they are developers, operations personnel, or administrators. The ability to affect an applications state is very powerful, so Komodo has a granular permissioning system to only provide this functionality to the intended users. The permissioning system is explained in detail in the [permissioning](/docs/permissioning) section. +Komodo is a system designed to be used by many users, whether they are developers, operations personnel, or administrators. The ability to affect an applications state is very powerful, so Komodo has a granular permissioning system to only provide this functionality to the intended users. The permissioning system is explained in detail in the [permissioning](/docs/resources/permissioning) section. User sign-on is possible using username / password, or with Oauth (Github and Google). See [Core Setup](./setup/index.mdx). \ No newline at end of file diff --git a/docsite/docs/resources/index.md b/docsite/docs/resources/index.md index f4ea578b1..a6db2ed00 100644 --- a/docsite/docs/resources/index.md +++ b/docsite/docs/resources/index.md @@ -10,7 +10,7 @@ Many resources need access to git repos / docker registries. There is an in-buil All resources which depend on git repos / docker registries are able to use these credentials to access private repos. ::: -## [Server](connect-servers) +## [Server](setup/connect-servers) - Configure the connection to periphery agents. - Set alerting thresholds. diff --git a/docsite/docs/resources/permissioning.md b/docsite/docs/resources/permissioning.md index d1480682b..88ba521aa 100644 --- a/docsite/docs/resources/permissioning.md +++ b/docsite/docs/resources/permissioning.md @@ -9,7 +9,7 @@ While Komodo can assign permissions to specific users directly, it is recommende Users can then be **added to multiple User Groups** and they **inherit the group's permissions**, similar to linux permissions. There is also an `Everyone` mode for User Groups, if this is enabled then **all users implicitly gain the groups permissions**. -For permissioning at scale, users can define [**User Groups in Resource Syncs**](/docs/sync-resources#user-group). +For permissioning at scale, users can define [**User Groups in Resource Syncs**](/docs/resources/sync-resources#user-group). ## Permission Levels diff --git a/docsite/docs/resources/variables.md b/docsite/docs/resources/variables.md index 7835c7ab4..35c54cac6 100644 --- a/docsite/docs/resources/variables.md +++ b/docsite/docs/resources/variables.md @@ -22,7 +22,7 @@ SOME_ENV_VAR = value_1 - **In the UI**, you can go to `Settings` page, `Variables` tab. Here, you can create some Variables to store in the Komodo database. - There is a "secret" option you can check, this will **prevent the value from exposure in any updates / logs**, as well as prevent access to the value to any **non-admin** Komodo users. - - Variables can also be managed in ResourceSyncs (see [example](/docs/sync-resources#deployments)) but should only be done for non-secret variables, to avoid committing sensitive data. You should manage secrets using one of the following options. + - Variables can also be managed in ResourceSyncs (see [example](/docs/resources/sync-resources#deployments)) but should only be done for non-secret variables, to avoid committing sensitive data. You should manage secrets using one of the following options. - **Mount a config file to Core**: https://komo.do/docs/setup/advanced#mount-a-config-file - In the Komodo Core config file, you can configure `secrets` using a block like: diff --git a/docsite/docs/setup/backup.md b/docsite/docs/setup/backup.md index 85c90f0b5..95c8f991d 100644 --- a/docsite/docs/setup/backup.md +++ b/docsite/docs/setup/backup.md @@ -63,7 +63,7 @@ so you may want to encrypt the files before backing up remotely if your backup s ## Remote Backups -Since database backup is actually a function of the [Komodo CLI](../cli), you can also backup directly to +Since database backup is actually a function of the [Komodo CLI](../ecosystem/cli), you can also backup directly to a remote server using the `ghcr.io/moghtech/komodo-cli` image. This service will backup once and then exit, so the scheduled deployment should still happen using a Procedure or Action: ```yaml