diff --git a/cspell.config.yaml b/cspell.config.yaml index de2ab1810c..b7ade20bf9 100644 --- a/cspell.config.yaml +++ b/cspell.config.yaml @@ -65,6 +65,7 @@ words: - Coverity - credrequests - creds + - crossplane - csanchez - daniilnedostup - dbchecker @@ -118,6 +119,8 @@ words: - hostedzone - Hostnames - hyperthreading + - hotspots + - Hotspots - importcert - ingresscontroller - initdb @@ -146,6 +149,7 @@ words: - krci - kubeadmin - kubeconfig + - kubeadm - kubelet - kubelogin - kuberocketci @@ -166,6 +170,7 @@ words: - multitenant - multivalued - mutatingwebhook + - mutatingwebhookconfigurations - mykolamarusenko - mypipe - myuser @@ -270,9 +275,11 @@ words: - userinfo - usermodel - vacuumdb + - validatingwebhookconfigurations - velero - Veracode - verion + - webhookconfigurations - wafv - waynesun - wildfly diff --git a/docs/assets/user-guide/argo-cd-preview/argo-cd-link.png b/docs/assets/user-guide/argo-cd-preview/argo-cd-link.png deleted file mode 100644 index 87a6305551..0000000000 Binary files a/docs/assets/user-guide/argo-cd-preview/argo-cd-link.png and /dev/null differ diff --git a/docs/assets/user-guide/argo-cd-preview/click-pipeline.png b/docs/assets/user-guide/argo-cd-preview/click-pipeline.png deleted file mode 100644 index ef9778bd70..0000000000 Binary files a/docs/assets/user-guide/argo-cd-preview/click-pipeline.png and /dev/null differ diff --git a/docs/assets/user-guide/argo-cd-preview/create-update-environment.png b/docs/assets/user-guide/argo-cd-preview/create-update-environment.png deleted file mode 100644 index d834cf81be..0000000000 Binary files a/docs/assets/user-guide/argo-cd-preview/create-update-environment.png and /dev/null differ diff --git a/docs/assets/user-guide/environments/grafana-monitoring-dashboard.png b/docs/assets/user-guide/environments/grafana-monitoring-dashboard.png deleted file mode 100644 index fa7d087593..0000000000 Binary files a/docs/assets/user-guide/environments/grafana-monitoring-dashboard.png and /dev/null differ diff --git a/docs/assets/user-guide/kuberocketci-portal-overview-page.png b/docs/assets/user-guide/kuberocketci-portal-overview-page.png deleted file mode 100644 index ffb57761a9..0000000000 Binary files a/docs/assets/user-guide/kuberocketci-portal-overview-page.png and /dev/null differ diff --git a/docs/assets/user-guide/observability-overview.png b/docs/assets/user-guide/observability-overview.png new file mode 100644 index 0000000000..480d8330ea Binary files /dev/null and b/docs/assets/user-guide/observability-overview.png differ diff --git a/docs/assets/user-guide/pipelines/click-pipeline-run-name.png b/docs/assets/user-guide/pipelines/click-pipeline-run-name.png deleted file mode 100644 index 7e89adc50d..0000000000 Binary files a/docs/assets/user-guide/pipelines/click-pipeline-run-name.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/delete-pipeline-run.png b/docs/assets/user-guide/pipelines/delete-pipeline-run.png deleted file mode 100644 index aaa2f12971..0000000000 Binary files a/docs/assets/user-guide/pipelines/delete-pipeline-run.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/edit-table-width.png b/docs/assets/user-guide/pipelines/edit-table-width.png deleted file mode 100644 index 18e988f346..0000000000 Binary files a/docs/assets/user-guide/pipelines/edit-table-width.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/edit-task-button.png b/docs/assets/user-guide/pipelines/edit-task-button.png deleted file mode 100644 index e7f11a0864..0000000000 Binary files a/docs/assets/user-guide/pipelines/edit-task-button.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/edit-task-window.png b/docs/assets/user-guide/pipelines/edit-task-window.png deleted file mode 100644 index 6e6628ab7e..0000000000 Binary files a/docs/assets/user-guide/pipelines/edit-task-window.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/history-tab.png b/docs/assets/user-guide/pipelines/history-tab.png deleted file mode 100644 index 907ddf5907..0000000000 Binary files a/docs/assets/user-guide/pipelines/history-tab.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/pipeline-details-tab.png b/docs/assets/user-guide/pipelines/pipeline-details-tab.png deleted file mode 100644 index d5027d41e1..0000000000 Binary files a/docs/assets/user-guide/pipelines/pipeline-details-tab.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/pipeline-results-tab.png b/docs/assets/user-guide/pipelines/pipeline-results-tab.png deleted file mode 100644 index f5b4b2637f..0000000000 Binary files a/docs/assets/user-guide/pipelines/pipeline-results-tab.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/pipelines-diagram-tab.png b/docs/assets/user-guide/pipelines/pipelines-diagram-tab.png deleted file mode 100644 index d3ba8ee195..0000000000 Binary files a/docs/assets/user-guide/pipelines/pipelines-diagram-tab.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/pipelines-overview.png b/docs/assets/user-guide/pipelines/pipelines-overview.png deleted file mode 100644 index c05411b8c3..0000000000 Binary files a/docs/assets/user-guide/pipelines/pipelines-overview.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/pipelines-tab.png b/docs/assets/user-guide/pipelines/pipelines-tab.png deleted file mode 100644 index 24dcff0150..0000000000 Binary files a/docs/assets/user-guide/pipelines/pipelines-tab.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/pipelines-view-yaml-tab.png b/docs/assets/user-guide/pipelines/pipelines-view-yaml-tab.png deleted file mode 100644 index e772c4c122..0000000000 Binary files a/docs/assets/user-guide/pipelines/pipelines-view-yaml-tab.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/restart-or-delete-pipeline.png b/docs/assets/user-guide/pipelines/restart-or-delete-pipeline.png deleted file mode 100644 index 50691b2fb6..0000000000 Binary files a/docs/assets/user-guide/pipelines/restart-or-delete-pipeline.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/restart-pipeline-run.png b/docs/assets/user-guide/pipelines/restart-pipeline-run.png deleted file mode 100644 index 5d08dba8bb..0000000000 Binary files a/docs/assets/user-guide/pipelines/restart-pipeline-run.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/restart-with-parameters.png b/docs/assets/user-guide/pipelines/restart-with-parameters.png deleted file mode 100644 index c65c4c04c6..0000000000 Binary files a/docs/assets/user-guide/pipelines/restart-with-parameters.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/results-in-codebase.png b/docs/assets/user-guide/pipelines/results-in-codebase.png deleted file mode 100644 index cfda03dba6..0000000000 Binary files a/docs/assets/user-guide/pipelines/results-in-codebase.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/results-in-pipelines-section.png b/docs/assets/user-guide/pipelines/results-in-pipelines-section.png deleted file mode 100644 index 14d5020de5..0000000000 Binary files a/docs/assets/user-guide/pipelines/results-in-pipelines-section.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/table-settings-button.png b/docs/assets/user-guide/pipelines/table-settings-button.png deleted file mode 100644 index 5dd833f0a0..0000000000 Binary files a/docs/assets/user-guide/pipelines/table-settings-button.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/table-settings-window.png b/docs/assets/user-guide/pipelines/table-settings-window.png deleted file mode 100644 index 203c83f2fb..0000000000 Binary files a/docs/assets/user-guide/pipelines/table-settings-window.png and /dev/null differ diff --git a/docs/assets/user-guide/pipelines/tasks-tab.png b/docs/assets/user-guide/pipelines/tasks-tab.png deleted file mode 100644 index 05606ebcd5..0000000000 Binary files a/docs/assets/user-guide/pipelines/tasks-tab.png and /dev/null differ diff --git a/docs/assets/user-guide/portal/click-username.png b/docs/assets/user-guide/portal/click-username.png deleted file mode 100644 index 0d8e91c175..0000000000 Binary files a/docs/assets/user-guide/portal/click-username.png and /dev/null differ diff --git a/docs/assets/user-guide/portal/cluster-tab.png b/docs/assets/user-guide/portal/cluster-tab.png deleted file mode 100644 index 6c67d7ff2a..0000000000 Binary files a/docs/assets/user-guide/portal/cluster-tab.png and /dev/null differ diff --git a/docs/assets/user-guide/portal/community-button.png b/docs/assets/user-guide/portal/community-button.png deleted file mode 100644 index a4056ccc9a..0000000000 Binary files a/docs/assets/user-guide/portal/community-button.png and /dev/null differ diff --git a/docs/assets/user-guide/portal/community-options.png b/docs/assets/user-guide/portal/community-options.png deleted file mode 100644 index 81a24e2a45..0000000000 Binary files a/docs/assets/user-guide/portal/community-options.png and /dev/null differ diff --git a/docs/assets/user-guide/portal/general-tab.png b/docs/assets/user-guide/portal/general-tab.png deleted file mode 100644 index 3c832df23a..0000000000 Binary files a/docs/assets/user-guide/portal/general-tab.png and /dev/null differ diff --git a/docs/assets/user-guide/portal/kubeconfig-tab.png b/docs/assets/user-guide/portal/kubeconfig-tab.png deleted file mode 100644 index dfd62bc330..0000000000 Binary files a/docs/assets/user-guide/portal/kubeconfig-tab.png and /dev/null differ diff --git a/docs/assets/user-guide/portal/portal-settings-button.png b/docs/assets/user-guide/portal/portal-settings-button.png deleted file mode 100644 index d46cd43ed5..0000000000 Binary files a/docs/assets/user-guide/portal/portal-settings-button.png and /dev/null differ diff --git a/docs/assets/user-guide/portal/user-info-tab.png b/docs/assets/user-guide/portal/user-info-tab.png deleted file mode 100644 index 0387609b01..0000000000 Binary files a/docs/assets/user-guide/portal/user-info-tab.png and /dev/null differ diff --git a/docs/assets/user-guide/sonarqube-and-deptrack-widgets.png b/docs/assets/user-guide/sonarqube-and-deptrack-widgets.png deleted file mode 100644 index 43749ac182..0000000000 Binary files a/docs/assets/user-guide/sonarqube-and-deptrack-widgets.png and /dev/null differ diff --git a/docs/assets/user-guide/tekton-pipelines/deploy-pipeline-configure-deploy.png b/docs/assets/user-guide/tekton-pipelines/deploy-pipeline-configure-deploy.png deleted file mode 100644 index 008b5288fb..0000000000 Binary files a/docs/assets/user-guide/tekton-pipelines/deploy-pipeline-configure-deploy.png and /dev/null differ diff --git a/docs/assets/user-guide/tekton-pipelines/release-pipeline.png b/docs/assets/user-guide/tekton-pipelines/release-pipeline.png deleted file mode 100644 index 312ade7c7e..0000000000 Binary files a/docs/assets/user-guide/tekton-pipelines/release-pipeline.png and /dev/null differ diff --git a/docs/assets/user-guide/tekton-pipelines/security-pipeline-results.png b/docs/assets/user-guide/tekton-pipelines/security-pipeline-results.png deleted file mode 100644 index d2f9afe4b4..0000000000 Binary files a/docs/assets/user-guide/tekton-pipelines/security-pipeline-results.png and /dev/null differ diff --git a/docs/assets/user-guide/tekton-pipelines/security-pipeline.png b/docs/assets/user-guide/tekton-pipelines/security-pipeline.png deleted file mode 100644 index 8c9ec35b4a..0000000000 Binary files a/docs/assets/user-guide/tekton-pipelines/security-pipeline.png and /dev/null differ diff --git a/docs/assets/user-guide/tekton-pipelines/test-pipelines.png b/docs/assets/user-guide/tekton-pipelines/test-pipelines.png deleted file mode 100644 index 0ae457b065..0000000000 Binary files a/docs/assets/user-guide/tekton-pipelines/test-pipelines.png and /dev/null differ diff --git a/docs/assets/user-guide/tekton-pipelines/trigger-build-pipeline-run.png b/docs/assets/user-guide/tekton-pipelines/trigger-build-pipeline-run.png deleted file mode 100644 index 9e43907593..0000000000 Binary files a/docs/assets/user-guide/tekton-pipelines/trigger-build-pipeline-run.png and /dev/null differ diff --git a/docs/user-guide/add-ai-assistant.md b/docs/user-guide/add-ai-assistant.md deleted file mode 100644 index 2ca844565a..0000000000 --- a/docs/user-guide/add-ai-assistant.md +++ /dev/null @@ -1,67 +0,0 @@ ---- - -title: "Add Gen AI Assistant" -sidebar_label: "Add Gen AI Assistant" -description: "Integrate a third-party AI assistant within KubeRocketCI to enhance platform navigation and obtain instant answers to queries directly in chat." - ---- - - -# Add Gen AI Assistant - - - - - -The KubeRocketCI portal allows you to connect the platform with a third-party AI assistant, enabling its use within the platform. This integration assists by providing platform-related information and answering any questions in the chat. The assistant's configuration is performed via the Configuration tab in the Gen AI section. - -## Prerequisites - -This option requires you to have your AI assistant configured on a dedicated instance first. Besides, assistant should be set up in the way it will have the [KubeRocketCI documentation](https://github.com/KubeRocketCI/docs) data indexed and added to the assistant's context. Therefore, before starting the integration procedure, ensure that your Gen AI instance is set up properly. - -## Set Up Integration - -To integrate the AI assistant, follow the steps below: - -1. Navigate to **KubeRocketCI** -> **Configuration** -> **Gen AI** and click the **+ Add link** button: - - ![Add quick link](../assets/user-guide/add-link-for-gen-ai.png "Add quick link") - -2. Fill in the fields and click **Create**: - - ![Set up quick link](../assets/user-guide/add-gen-ai-quick-link.png "Set up quick link") - -3. Navigate to **KubeRocketCI** -> **Configuration** -> **Gen AI** and click the **+ Add integration** button: - - ![Integrate Gen AI](../assets/user-guide/add-gen-ai.png "Integrate Gen AI") - -4. Fill in the required fields: - - * **Quick Link URL** - This link will be attached to the quick links presented on the KubeRocketCI portal main page. It should lead to the Gen AI instance endpoint. - * **API URL** - This is the URL address of the assistant's API server. - * **Assistant ID** - Enter the ID of a dedicated assistant that will be used to interact with you. - * **Token** - This token will be used to get authorized access to your Gen AI instance. Ensure that sufficient permissions are set so that the platform can interact with the assistant using this token. - - ![Integrate Gen AI](../assets/user-guide/gen-ai-integration.png "Integrate Gen AI") - -5. Click the **Save** button. - -## Verify Integration - -As soon as the integration procedure is completed, click the AI chat button at the bottom-right corner of the screen: - - ![AI chat window](../assets/user-guide/ai-chat-button.png "AI chat window") - -Type something in the chat to make sure the assistant works properly: - - ![Ask assistant](../assets/user-guide/ask-assistant.png "Ask assistant") - -When you close the chat and reopen it, a new chat begins. You can see the chat history by clicking the clock icon: - - ![Chat history button](../assets/user-guide/history_button.png "Chat history button") - -You can also create another chat by clicking the **+ New chat** button: - - ![Create new chat](../assets/user-guide/ai-chat-history.png "Create new chat") - -Depending on the assistant's settings, it will be able to provide platform-related guidance, such as how to onboard a library or deploy an application, and address any questions you may have. diff --git a/docs/user-guide/add-application.md b/docs/user-guide/add-application.md index c1c2a14458..88a7d585a7 100644 --- a/docs/user-guide/add-application.md +++ b/docs/user-guide/add-application.md @@ -16,81 +16,66 @@ description: "Master application creation in KubeRocketCI, from cloning reposito KubeRocketCI portal allows you to create an application, clone an existing repository with the application to your Version Control System (VCS), or using an external repository and importing an application to the environment. When an application is created or cloned, the system automatically generates a corresponding repository within the integrated Version Control System. You can create an Application [in YAML](#create-application-in-yaml) or [via the two-step menu](#create-application-via-ui) in the dialog. -To add an application, navigate to the **Components** section on the navigation bar and click **+ Create component**: +The **Create Application** dialog contains four steps: - ![Create new application](../assets/user-guide/components/components-create-new-codebase.png "Create new application") +* Initial Setup +* Git & Project Info +* Build Config +* Review -Once clicked, the **Create new component** dialog will appear, then select **Application** and click **Next**: - ![Application info](../assets/user-guide/components/application/application-create-new-application.png "Application info") +To add an application, navigate to the **Projects** section on the navigation bar and click **+ Create Project**. -Choose one of the strategies and click **Create**: +## Initial Setup - ![Select strategy](../assets/user-guide/components/components-select-strategy.png "Select strategy") +Once clicked, the **Create new project** dialog will appear. In this dialog, you can make a choice: -* **Create from template** – creates a project on the pattern in accordance with an application language, a build tool, and a framework. This strategy is recommended for projects that start developing their applications from scratch. +* **Select Ready Template** - this option allows you to select a preconfigured, ready-to-go application (e.g., Antora documentation or Echo server). +* **Custom Configuration** - this option allows you create any of the supported Project type. In this case, you should select **Application**. -* **Import project** - allows using existing VCS repository to integrate with KubeRocketCI. While importing the existing repository, select the Git server from the drop-down list and define the relative path to the repository, such as `epmd-edp/python-python-flask`. +Choose one of the strategies and click **Continue**: - :::note - In order to use the **Import project** strategy, make sure to adjust it with the [Integrate GitLab/GitHub in Tekton](../user-guide/add-git-server.md) page. - ::: +* **Create** – creates a project on the pattern in accordance with an application language, a build tool, and a framework. This strategy is recommended for projects that start developing their applications from scratch. -* **Clone project** – clones the indicated repository into KubeRocketCI. While cloning the existing repository, it is required to fill in the **Repository URL** field and specify the credentials if needed: +* **Import** - allows using existing VCS repository to integrate with KubeRocketCI. While importing the existing repository, select the Git server from the drop-down list and define the relative path to the repository, such as `epmd-edp/python-python-flask`. - ![Clone application](../assets/user-guide/components/application/application-clone-application.png "Clone application") +* **Clone** – clones the indicated repository into KubeRocketCI. While cloning the existing repository, it is required to fill in the **Repository URL** field and specify the credentials if needed: -## Create Application in YAML +## Git & Project Info -Click **Edit YAML** in the upper-right corner of the **Create Application** dialog to open the YAML editor and create the Application. +In our example, we will use the **Create** strategy: -![Edit YAML](../assets/user-guide/components/application/application-yaml-edit.png "Edit YAML") +Select all the settings that define how the application will be added to Git server: -To edit YAML in the minimal editor, turn on the **Use minimal editor** toggle in the upper-right corner of the **Create Application** dialog. + * **Git server** - the pre-configured server where the component will be hosted. Select one from the drop-down list. Please refer to the [Manage Git Servers](git-server-overview.md) page to learn how to create the one. + * **Git URL Path** - the relative path to the Git repository where codebase will be created (e.g., `epmd-edp` or `my-github-username`). + * **Project name** - the name of the application. Must be at least two characters using the lower-case letters, numbers and inner dashes. + * **Default Branch** - the default branch the Project will be created with. The default branch cannot be deleted. + * **Description** - brief and concise description that explains the purpose of the application. + * **Private** - by default, all the created Projects have private visibility settings in your Git account. Uncheck this option to create a public Git repository. + * **Empty project** - check this box to create an application with an empty repository. The empty repository option is available only for the **Create** strategy. -To save the changes, select the **Save & Apply** button. -## Create Application via UI +## Build Config -The **Create Application** dialog contains two steps: +Specify the application language and versioning properties: -* The Codebase Info Menu -* The Advanced Settings Menu + * **Code Language** - defines the code language with its supported frameworks: -### Codebase Info Menu + * Java – selecting a specific Java version (17, 21, and 25 are available; Java 8 and 11 have been deprecated starting from KubeRocketCI version 3.12). + * JavaScript - selecting JavaScript allows using React, Vue, Angular, Express, Next.js and Antora frameworks. + * Python - selecting Python allows using the Python v.3.8, FastAPI, Flask frameworks. + * Go - selecting Go allows using the Beego, Gin and Operator SDK frameworks. + * C# - selecting C# allows using the .Net v.3.1 and .Net v.6.0 frameworks. + * Helm - selecting Helm allows using the Helm framework. + * Other - selecting Other allows extending the default code languages when creating a codebase with the clone/import strategy. -Follow the instructions below to fill in the fields of the **Codebase Info** menu: - - In our example, we will use the **Create from template** strategy: - - ![Create application](../assets/user-guide/components/application/application-create-application.png "Create application") - -1. Select all the settings that define how the application will be added to Git server: - - * **Git server** - the pre-configured server where the component will be hosted. Select one from the drop-down list. Please refer to the [Manage Git Servers](git-server-overview.md) page to learn how to create the one. - * **Repository name** - the relative path to the Git repository where codebase will be created (e.g., `epmd-edp/python-python-flask`). - * **Component name** - the name of the application. Must be at least two characters using the lower-case letters, numbers and inner dashes. - * **Description** - brief and concise description that explains the purpose of the application. - * **Empty project** - check this box to create an application with an empty repository. The empty repository option is available only for the **Create from template** strategy. - -2. Specify the application language properties: - - * **Application Code Language** - defines the code language with its supported frameworks: - - * Java – selecting a specific Java version (17, 21, and 25 are available; Java 8 and 11 have been deprecated starting from KubeRocketCI version 3.12). - * JavaScript - selecting JavaScript allows using React, Vue, Angular, Express, Next.js and Antora frameworks. - * Python - selecting Python allows using the Python v.3.8, FastAPI, Flask frameworks. - * Go - selecting Go allows using the Beego, Gin and Operator SDK frameworks. - * C# - selecting C# allows using the .Net v.3.1 and .Net v.6.0 frameworks. - * Helm - selecting Helm allows using the Helm framework. - * Other - selecting Other allows extending the default code languages when creating a codebase with the clone/import strategy. - - :::note - The **Create from template** strategy does not allow to customize the default code language set. - ::: + :::note + The **Create from template** strategy does not allow to customize the default code language set. + ::: * **Language version/framework** - defines the specific framework or language version of the application. The field depends on the selected code language. - * **Select Build Tool** - allows to choose the build tool to use. A set tools and can be changed in accordance with the selected code language. + * **Build Tool** - allows to choose the build tool to use. A set tools and can be changed in accordance with the selected code language. * Java - selecting Java allows using the Gradle or Maven tool. * JavaScript - selecting JavaScript allows using the NPM or PNPM tool. @@ -107,35 +92,21 @@ Follow the instructions below to fill in the fields of the **Codebase Info** men Tekton pipelines offer built-in support for Java Maven Multi-Module projects. These pipelines are capable of recognizing Java deployable modules based on the information in the **pom.xml** file and performing relevant deployment actions. It's important to note that although the Dockerfile is typically located in the root directory, Kaniko, the tool used for building container images, uses the targets folder within the deployable module's context. For a clear illustration of a Multi-Module project structure, please refer to this [example](https://github.com/epmd-edp/java-maven-java17-multimodule.git) on GitHub, which showcases a commonly used structure for Java Maven Multi-Module projects. ::: -### Advanced Settings Menu - -In the **Advanced Settings** menu, specify the branch options and define the Jira settings: - - ![Advanced settings](../assets/user-guide/components/application-specify-advanced-settings.png "Advanced settings") - -* **Default branch** - the name of the branch where you want the development to be performed. - - :::note - The default branch cannot be deleted. - ::: - -* **Deployment Options** - Select the deployment option available. - * **helm-chart**: Application will be deployed as a Helm chart using the Argo CD tool. - * **rpm-package**: Application will be deployed as an rpm package using the Ansible tool. For more details, please refer to the [Deploy RPM Packages](../operator-guide/cd/deploy-rpm.md) page. - * **Codebase versioning type** - defines how will the application tag be changed once the new image version is built. There are two versioning types: * **default**: Using the `default` versioning type, in order to specify the version of the current artifacts, images, and tags in the Version Control System, a developer should navigate to the corresponding file and change the version **manually**. * **semver**: Using the `semver` versioning type, a developer indicates the version number from which all the artifacts will be versioned and, as a result, **automatically** registered in the corresponding file (e.g. pom.xml). When selecting the `semver` versioning type, the extra fields will appear, type the version number from which you want the artifacts to be versioned: - ![Semver versioning](../assets/user-guide/components/components-edp-versioning.png "Semver versioning") - :::note The **Start Version From** field should be filled out in compliance with the semantic versioning rules, e.g. 1.2.3 or 10.10.10. Please refer to the [Semantic Versioning](https://semver.org/) page for details. ::: -* **Specify the pattern to validate a commit message** - the regular expression used to indicate the pattern that is followed on the project to validate a commit message in the code review pipeline. An example of the pattern: `^[PROJECT_NAME-d{4}]:.*$`. +* **Deployment Options** - select the deployment option available. + * **helm-chart**: Application will be deployed as a Helm chart using the Argo CD tool. + * **rpm-package**: Application will be deployed as an rpm package using the Ansible tool. For more details, please refer to the [Deploy RPM Packages](../operator-guide/cd/deploy-rpm.md) page. - ![JIRA integration](../assets/user-guide/components/components-jira-server.png "JIRA integration") +* **CI Pipelines** - select the available CI pipelines provider. Tekton is used by default. + +* **Specify the pattern to validate a commit message** - the regular expression used to indicate the pattern that is followed on the project to validate a commit message in the code review pipeline. An example of the pattern: `^[PROJECT_NAME-d{4}]:.*$`. * **Integrate with Jira server** - this check box is used in case it is required to connect Jira tickets with the commits and have a respective label in the **Fix Version** field. @@ -148,7 +119,6 @@ and have a respective label in the **Fix Version** field. * **Specify the pattern to find a Jira ticket number in a commit message** - based on this pattern, the value from KubeRocketCI will be displayed in Jira. - ![Mapping field name](../assets/user-guide/components/components-jira-advanced-mapping.png "Mapping fields") * **Mapping field name** - the section where the additional Jira fields are specified the names of the Jira fields that should be filled in with attributes from KubeRocketCI: @@ -164,7 +134,10 @@ and have a respective label in the **Fix Version** field. * Click the bin icon to remove the Jira field name. -Click the **Create** button to add the application to the Components list. + +## Review and Create + +The **Review an Create** window allows to ensure the application configuration suits your needs and verify you entered specifications correctly. :::note After the complete adding of the application, inspect the [Manage Applications](application.md) page to learn how you can operate applications. diff --git a/docs/user-guide/add-autotest.md b/docs/user-guide/add-autotest.md index 890b2955fc..1369d196bd 100644 --- a/docs/user-guide/add-autotest.md +++ b/docs/user-guide/add-autotest.md @@ -1,9 +1,7 @@ --- - title: "Add Autotest" sidebar_label: "Add Autotest" description: "Learn how to add autotests in KubeRocketCI, integrating them into CI/CD workflows for enhanced quality assurance and deployment." - --- @@ -13,140 +11,104 @@ description: "Learn how to add autotests in KubeRocketCI, integrating them into -KubeRocketCI portal allows you to clone an existing repository with the autotest to your Version Control System (VCS), or using an external repository and adding an autotest for further running in stages or using them as quality gates for applications. +KubeRocketCI portal allows you to clone an existing repository with the autotest to your Version Control System (VCS), or use an external repository and import an autotest to the environment for running in stages or using as quality gates for applications. When an autotest is cloned or imported, the system automatically generates a corresponding repository within the integrated Version Control System. You can create an Autotest [in YAML](#create-autotest-in-yaml) or [via the dialog](#create-autotest-via-ui).
-When an autotest is cloned, the system automatically generates a corresponding repository within the integrated VCS. You can create an autotest [in YAML](#create-autotest-in-yaml) or [via the two-step menu](#create-autotest-via-ui) in the dialog. - -:::info - Please refer to the [Add Application](add-application.md) section for the details on how to add an application codebase type. - For the details on how to use autotests as quality gates, please refer to the [Stages Menu](add-cd-pipeline.md) section of the [Add Environment](add-cd-pipeline.md) documentation. -::: - -To add an autotest, navigate to the **Components** section on the navigation bar and click **+ Create component**: - - ![Create new autotest](../assets/user-guide/components/components-create-new-codebase.png "Create new autotest") - -Once clicked, the **Create new component** dialog will appear, then select **Autotest** and click **Next**: - - ![Create new autotest](../assets/user-guide/components/components-select-type-new-codebase.png "Create new autotest") - -Choose one of the strategies and click **Create**: - - ![Select strategy](../assets/user-guide/components/autotests/autotests-select-strategy.png "Select strategy") - -* **Clone project** – clones the indicated repository into KubeRocketCI. While cloning the existing repository, it is required to fill in the **Repository URL** field and specify the credentials if needed. - -* **Import project** - allows using existing VCS repository to integrate with KubeRocketCI. While importing the existing repository, select the Git server from the drop-down list and define the relative path to the repository, such as `/epmd-edp/examples/basic/edp-auto-tests-simple-example`. - - :::note - In order to use the **Import project** strategy, make sure to adjust it with the [Integrate GitLab/GitHub With Tekton](../user-guide/add-git-server.md) page. - ::: - -## Create Autotest in YAML - -Click **Edit YAML** in the upper-right corner of the **Create Autotest** dialog to open the YAML editor and create an autotest: +The **Create Autotest** dialog contains four steps: -![Edit YAML](../assets/user-guide/components/autotests/autotests-yaml-edit.png "Edit YAML") +* Initial Setup +* Git & Project Info +* Build Config +* Review -To edit YAML in the minimal editor, turn on the **Use minimal editor** toggle in the upper-right corner of the **Create Autotest** dialog. +To add an autotest, navigate to the **Projects** section on the navigation bar and click **+ Create Project**. -To save the changes, select the **Save & Apply** button. +## Initial Setup -## Create Autotest via UI +Once clicked, the **Create new project** dialog will appear. In this dialog, you can make a choice: -The **Create Autotest** dialog contains the two steps: +* **Select Ready Template** – this option allows you to select a preconfigured, ready-to-go autotest template. +* **Custom Configuration** – this option allows you to create any of the supported Project types. In this case, you should select **Autotest**. -* The Codebase Info Menu -* The Advanced Settings Menu +Choose one of the strategies and click **Continue**: -### The Codebase Info Menu +* **Import** – allows using an existing VCS repository to integrate with KubeRocketCI. While importing the existing repository, select the Git server from the drop-down list and define the relative path to the repository, such as `epmd-edp/examples/basic/edp-auto-tests-simple-example`. -In our case, we will use the **Clone** strategy: +* **Clone** – clones the indicated repository into KubeRocketCI. While cloning the existing repository, it is required to fill in the **Repository URL** field and specify the credentials if needed. - ![Clone autotest](../assets/user-guide/components/autotests/autotests-clone-autotests.png "Clone autotest") - -1. Select all the settings that define how the autotest will be added to Git server: - - * **Git server** - the pre-configured server where the component will be hosted. Select one from the drop-down list. Please refer to the [Manage Git Servers](git-server-overview.md) page to learn how to create the one. - * **Repository name** - the relative path to the repository, such as `/epmd-edp/examples/basic/edp-auto-tests-simple-example`. - * **Component name** - the name of the autotest. Must be at least two characters using the lower-case letters, numbers and inner dashes. - * **Description** - brief and concise description that explains the purpose of the autotest. - -2. Specify the autotest language properties: - - * **Autotest code language** - defines the code language with its supported frameworks. Selecting **Other** allows extending the default code languages and get the necessary build tool. - * **Language version/framework** - defines the specific framework or language version of the autotest. The field depends on the selected code language. Specify Java 17, Java 21, or Java 25 to be used. Java 8 and 11 have been deprecated starting from KubeRocketCI version 3.12. - * **Build Tool** - allows to choose the build tool to use. In case of autotests, Gradle and Maven are available. - * **Autotest report framework** - all the autotest reports will be created in the Allure framework by default. - -3. Click the **Next** button to proceed. - -### The Advanced Settings Menu - -In the **Advanced Settings** menu, specify the branch options and define the Jira settings: - - ![Advanced settings](../assets/user-guide/components/autotests/autotests-advanced-settings-autotest.png "Advanced settings") - -* **Default branch** - the name of the branch where you want the development to be performed. +:::note +Autotest does not support the **Create** strategy. Use **Import** or **Clone** to add an autotest. +::: - :::info - The default branch cannot be deleted. - ::: +## Git & Project Info -* **Codebase versioning type** - defines how will the autotest tag be changed once the new image version is built. There are two versioning types: +In our example, we will use the **Import** strategy: - * **default**: Using the `default` versioning type, in order to specify the version of the current artifacts, images, and tags in the Version Control System, a developer should navigate to the corresponding file and change the version **manually**. - * **semver**: Using the `semver` versioning type, a developer indicates the version number from which all the artifacts will be versioned and, as a result, **automatically** registered in the corresponding file (e.g. pom.xml). When selecting the `semver` versioning type, the extra fields will appear, type the version number from which you want the artifacts to be versioned: +Select all the settings that define how the autotest will be added to the Git server: - ![Semver versioning](../assets/user-guide/components/components-edp-versioning.png "Semver versioning") +* **Git server** – the pre-configured server where the component will be hosted. Select one from the drop-down list. Please refer to the [Manage Git Servers](git-server-overview.md) page to learn how to create one. +* **Git URL Path** – the relative path to the Git repository where the codebase will be created (e.g., `epmd-edp` or `my-github-username`). +* **Project name** – the name of the autotest. Must be at least two characters using lower-case letters, numbers, and inner dashes. +* **Default Branch** – the default branch the Project will be created with. The default branch cannot be deleted. +* **Description** – brief and concise description that explains the purpose of the autotest. +* **Private** – by default, all created Projects have private visibility settings in your Git account. Uncheck this option to create a public Git repository. - Type the version number from which you want the artifacts to be versioned. +## Build Config - :::note - The **Start Version From** field must be filled out in compliance with the semantic versioning rules, e.g. 1.2.3 or 10.10.10. Please refer to the [Semantic Versioning](https://semver.org/) page for details. - ::: +Specify the autotest language and versioning properties: -* **Specify the pattern to validate a commit message** - the regular expression used to indicate the pattern that is followed on the project to validate a commit message in the code review pipeline. An example of the pattern: `^[PROJECT_NAME-d{4}]:.*$`. +* **Code Language** – defines the code language with its supported frameworks. For autotests, **Other** is often used to extend the default code languages when using the Clone/Import strategy. +* **Language version/framework** – defines the specific framework or language version of the autotest. The field depends on the selected code language. Specify Java 17, Java 21, or Java 25 to be used. Java 8 and 11 have been deprecated starting from KubeRocketCI version 3.12. +* **Build Tool** – allows you to choose the build tool to use. For autotests, Gradle and Maven are available. +* **Autotest report framework** – all autotest reports are created in the Allure framework by default. - ![Jira integration](../assets/user-guide/components/components-jira-server.png) +* **Codebase versioning type** – defines how the autotest tag will be changed once the new image version is built. There are two versioning types: + * **default**: Using the `default` versioning type, to specify the version of the current artifacts, images, and tags in the Version Control System, a developer should navigate to the corresponding file and change the version **manually**. + * **semver**: Using the `semver` versioning type, a developer indicates the version number from which all artifacts will be versioned and, as a result, **automatically** registered in the corresponding file (e.g. pom.xml). When selecting the `semver` versioning type, extra fields will appear; type the version number from which you want the artifacts to be versioned. -* **Integrate with Jira server** - this check box is used in case it is required to connect Jira tickets with the commits -and have a respective label in the **Fix Version** field. + :::note + The **Start Version From** field should be filled out in compliance with the semantic versioning rules, e.g. 1.2.3 or 10.10.10. Please refer to the [Semantic Versioning](https://semver.org/) page for details. + ::: - :::note - To adjust the Jira integration functionality, first apply the necessary changes described on the [Adjust Jira Integration](../operator-guide/project-management-and-reporting/jira-integration.md) page. - ::: +* **Specify the pattern to validate a commit message** – the regular expression used to indicate the pattern that is followed on the project to validate a commit message in the code review pipeline. An example of the pattern: `^[PROJECT_NAME-d{4}]:.*$`. -* **Jira Server** - the integrated Jira server with related Jira tasks. +* **Integrate with Jira server** – this check box is used in case it is required to connect Jira tickets with the commits and have a respective label in the **Fix Version** field. -* **Specify the pattern to find a Jira ticket number in a commit message** - based on this pattern, the value from KubeRocketCI will be displayed in Jira. + :::note + To adjust the Jira integration functionality, first apply the necessary changes described on the [Adjust Jira Integration](../operator-guide/project-management-and-reporting/jira-integration.md) page. + ::: - ![Mapping field name](../assets/user-guide/components/components-jira-advanced-mapping.png "Mapping field name") +* **Jira Server** – the integrated Jira server with related Jira tasks. -* **Mapping field name** - the section where the additional Jira fields are specified the names of the Jira fields that should be filled in with attributes from KubeRocketCI: +* **Specify the pattern to find a Jira ticket number in a commit message** – based on this pattern, the value from KubeRocketCI will be displayed in Jira. - * Select the name of the field in a Jira ticket. The available fields are the following: _Fix Version/s_, _Component/s_ and _Labels_. +* **Mapping field name** – the section where the additional Jira fields are specified, i.e. the names of the Jira fields that should be filled in with attributes from KubeRocketCI: + * Select the name of the field in a Jira ticket. The available fields are: _Fix Version/s_, _Component/s_, and _Labels_. * Click the **Add** button to add the mapping field name. + * Enter the Jira pattern for the field name: - * Enter Jira pattern for the field name: - - * For the **Fix Version/s** field, select the **EDP_VERSION** variable that represents an KubeRocketCI upgrade version, as in _2.7.0-SNAPSHOT_.Combine variables to make the value more informative. For example, the pattern **EDP_VERSION-EDP_COMPONENT** will be displayed as _2.7.0-SNAPSHOT-nexus-operator_ in Jira. - * For the **Component/s** field select the **EDP_COMPONENT** variable that defines the name of the existing repository. For example, _nexus-operator_. - * For the **Labels** field select the **EDP_GITTAG** variable that defines a tag assigned to the commit in Git Hub. For example, _build/2.7.0-SNAPSHOT.59_. + * For the **Fix Version/s** field, select the **EDP_VERSION** variable that represents a KubeRocketCI upgrade version, as in _2.7.0-SNAPSHOT_. Combine variables to make the value more informative. For example, the pattern **EDP_VERSION-EDP_COMPONENT** will be displayed as _2.7.0-SNAPSHOT-nexus-operator_ in Jira. + * For the **Component/s** field, select the **EDP_COMPONENT** variable that defines the name of the existing repository. For example, _nexus-operator_. + * For the **Labels** field, select the **EDP_GITTAG** variable that defines a tag assigned to the commit in GitHub. For example, _build/2.7.0-SNAPSHOT.59_. * Click the bin icon to remove the Jira field name. -After the complete adding of the autotest, inspect the [Autotest Overview](autotest.md) page to learn how you can operate applications. +## Review and Create + +The **Review and Create** window allows you to ensure the autotest configuration suits your needs and verify you entered the specifications correctly. + +:::note +After the complete adding of the autotest, inspect the [Manage Autotests](autotest.md) page to learn how you can operate autotests. +::: ## Related Articles * [Manage Autotests](autotest.md) * [Add Application](add-application.md) -* [Add CD Pipelines](add-cd-pipeline.md) +* [Add CD Pipeline](add-cd-pipeline.md) * [Adjust Jira Integration](../operator-guide/project-management-and-reporting/jira-integration.md) -* [Manage Git Providers](../user-guide/add-git-server.md) +* [Manage Git Servers](git-server-overview.md) diff --git a/docs/user-guide/add-cd-pipeline.md b/docs/user-guide/add-cd-pipeline.md index 2736abcd81..42e8c69c86 100644 --- a/docs/user-guide/add-cd-pipeline.md +++ b/docs/user-guide/add-cd-pipeline.md @@ -1,137 +1,116 @@ --- -title: "Add Deployment Flow" -sidebar_label: "Add Deployment Flow" -description: "Learn how to establish Deployment Flows in KubeRocketCI for streamlined GitOps, automated deployment, and efficient multi-environment management." +title: "Add Deployment" +sidebar_label: "Add Deployment" +description: "Learn how to establish Deployments in KubeRocketCI for streamlined GitOps, automated deployment, and efficient multi-environment management." --- -# Add Deployment Flow +# Add Deployment -In KubeRocketCI, deployments are managed through Deployment Flows, a versatile mechanism that enables GitOps, automated deploy, promotion within pipelines, and multi-environment support. +In KubeRocketCI, deployments are managed through Deployments, a versatile mechanism that enables GitOps, automated deploy, promotion within pipelines, and multi-environment support. -Navigate to the **Deployment flows** section on the navigation bar and click **+ Create deployment flow**. Once clicked, the **Create deployment flow** dialog will appear. +The creation of the Deployment becomes available as soon as an application is created including its provisioning in a branch and the necessary entities for the Deployment. If you don't have the application yet, create by following the guidelines in the [Add Application](./add-application.md) page. Additionally, ensure to familiarize yourself with the [Manage GitOps](gitops.md) page as it is required to add a GitOps repository first before creating an Deployment. -The creation of the Deployment Flow becomes available as soon as an application is created including its provisioning -in a branch and the necessary entities for the Deployment Flow. You can create a Deployment Flow [in YAML](#create-deployment-flow-in-yaml) or [via the two-steps menu](#create-deployment-flow) in the dialog. +## Create Deployment -## Create Deployment Flow +The **Create new deployment** dialog has three steps: **Applications** and **Pipeline Configuration**, and **Review**. -The **Create Deployment Flow** dialog has two steps: **Enter name** and **Add applications**. +Navigate to the **Deployments** section on the navigation bar and click **+ Create deployment**. Once clicked, the **Create new deployment** dialog will appear. -### The Deployment Flow Menu +### Select Applications -Before proceeding, ensure to familiarize yourself with the [Manage GitOps](gitops.md) page as it is required to add a GitOps repository first before creating an environment: +In the **Applications** stage: - ![Add GitOps repository](../assets/user-guide/environments/add-gitops-repo.png "Add GitOps repository") +1. Select the application(s) you are going to deploy -To create a deployment flow, follow the steps below: +2. Define target branches for the application(s). -1. Navigate to the **Deployment Flows** tab and click the **+ Create Deployment Flow** button: +3. Click **Continue**. - ![Deployment Flows menu](../assets/user-guide/environments/edp-portal-create-new-pipeline.png "Deployment Flows menu") +### Configure Pipeline Settings -2. The **Enter name** tab of the **Create Deployment Flow** window is presented below: +In the **Pipeline Configuration** stage, specify following configuration: - ![Create CD pipeline](../assets/user-guide/environments/edp-portal-pipeline-menu.png "Create CD pipeline") +1. Enter the deployment name that will be displayed in the Deployments list. Enter at least two characters, use the lower-case letters, numbers, and dashes. - 1. Enter the deployment flow name that will be displayed in the Deployment Flows list. Enter at least two characters, use the lower-case letters, numbers, and dashes. +2. Enter informative but concise description. - 2. Enter informative but concise description. +3. Select the necessary application from the **Mapping field name** drop-down menu and click by it name. - 3. Click the **Next** button to move onto the **Add applications** tab. +4. Specify the application parameters: - :::note - The namespace created by the environment has the following pattern combination: **[KubeRocketCI namespace]-[environment name]-[stage name]**. - Please be aware that the namespace length should not exceed 63 symbols. - ::: - -3. The **Component** tab of the **Environments** menu is presented below: - - ![Environment applications](../assets/user-guide/environments/edp-portal-cd-pipeline-applications.png "Environment applications") - - 1. Select the necessary application from the **Mapping field name** drop-down menu and click by it name. - - 2. Specify the application parameters: - - * **Branch** - Select the application branch from the drop-down menu. + * **Branch** - Select the application branch from the drop-down menu. - * **Promote applications** - When enabled, applications will be promoted through stages using the latest successful build from each previous stage. When disabled, all stages will deploy the same version that was initially selected for the pipeline, regardless of any newer builds. + * **Promote applications** - When enabled, applications will be promoted through stages using the latest successful build from each previous stage. When disabled, all stages will deploy the same version that was initially selected for the pipeline, regardless of any newer builds. - :::note - If there is another deployed environment stage with the respective codebase stream (equal image stream as an OpenShift term), the pattern combination will be as follows: `[pipeline name]-[stage name]-[application name]-[verified]`. - ::: - -4. Click the **Create** button to finish deployment flow configuration and proceed with configuring environment. - - ![Adding stage](../assets/user-guide/environments/edp-portal-environment-final.png "Adding stage") - -### The Environments Menu - -Stages are created the following way: + :::note + If there is another deployed environment stage with the respective codebase stream (equal image stream as an OpenShift term), the pattern combination will be as follows: `[pipeline name]-[stage name]-[application name]-[verified]`. + ::: -1. On the **Environments** menu, click the **Create Environment** button: +5. Click **Continue**. - ![CD stages](../assets/user-guide/environments/edp-portal-cd-pipeline-add-stages.png "CD stages") +### Review and Create -2. On the **Configure Stage** tab of the **Create Stage** menu, fill in the necessary fields in the corresponding window and click **Next**: +Ensure you specified the Deployment configuration correctly and click the **Create** button to finish deployment configuration and proceed with configuring environment. - ![CD stages](../assets/user-guide/environments/edp-portal-cd-pipeline-stages.png "CD stages") + :::note + The namespace created by the environment has the following pattern combination: **[KubeRocketCI namespace]-[environment name]-[stage name]**. + Please be aware that the namespace length should not exceed 63 symbols. + ::: - Set the proper cluster options: +## Create Environment - * **Cluster** - Choose the cluster to deploy the stage in; - * **Stage name** - Enter the stage name; - * **Namespace** - Specify the Kubernetes namespace where the resources will be deployed in. By default, this field is pre-populated automatically but keep in mind that the namespace name must be no longer than 63 symbols; - * **Description** - Enter the description for this stage; - * **Trigger type** - Select the trigger type. The key benefit of the automatic deploy feature is to keep environments up-to-date. The available trigger types are _Manual_ and _Auto_. When the _Auto_ trigger type is chosen, the environment will initiate automatically once the image is built. _Manual_ implies that user has to perform deploy manually by clicking the **Deploy** button in the environment menu. Please refer to the [Architecture Scheme of CD Pipeline Operator](https://github.com/epam/edp-cd-pipeline-operator/blob/master/docs/arch.md) page for additional details. - * **Pipeline template** - Choose a predefined blueprint outlining the deployment process for your application. While you have the option to incorporate custom deployment templates by generating a resource of the PipelineTemplate category, you can also opt for one of the preexisting options: with autotests or without. - * **Clean Pipeline template** - Choose one of the pre-defined pipelines offered by KubeRocketCI to define the cleanup logic. In case if you have specific requirements to the environment cleanup procedure, you can make up your own cleanup pipeline to use, which will be added to the **Clean Pipeline template** drop-down list. +After creating a Deployment, select **Open Deployment** on the congratulations page. If you didn't, open the Deployment details page by clicking on its name. -3. On the **Add quality gates** tab, specify your quality gates and click **Create**: +### Basic Configuration - ![Add quality gates menu](../assets/user-guide/environments/edp-portal-cd-adding-stage1.png "Add quality gates menu") +Environments are created the following way: - Select the quality gate options: - * **Quality gate type** - Select the quality gate type: - * Manual - The promoting process should be confirmed in Tekton manually; - * Autotests - The promoting process should be confirmed by the successful passing of the autotests; - * **Step name** - Type the step name, which will be displayed in Tekton, for every quality gate; - * **Autotest** - Select the previously created [autotest](add-autotest.md) name; - * **Autotest branch** - Specify a branch for the autotest. +1. On the **Deployment details** menu, click the **Create Environment** button. - :::info Execution sequence - The image promotion and execution of the pipelines depend on the sequence in which the environments are added. - ::: +2. On the **Configure Stage** tab of the **Create Stage** menu, fill in the necessary fields in the corresponding window: -4. Click the **Go to environment** button to start the provisioning of the pipeline: + * **Cluster** - Choose the cluster to deploy the stage in; + * **Environment name** - Enter the Environment name; + * **Deploy Namespace** - Specify the Kubernetes namespace where the resources will be deployed in. By default, this field is pre-populated automatically but keep in mind that the namespace name must be no longer than 63 symbols; + * **Description** - Enter the description for this stage; - ![Adding stage](../assets/user-guide/environments/edp-portal-stage-final.png "Adding stage") +3. Click **Continue**. -As a result, a new environment will be created in the environments list. You can switch between the detailed and compact view using the **Show more/less details** buttons: +### Pipeline Configuration - ![Switch view](../assets/user-guide/environments/edp-portal-switch-view.png "Switch view") +In this tab, you need to configure deployment approach: -## Create Deployment Flow in YAML + * **Trigger type** - Select the trigger type. The key benefit of the automatic deploy feature is to keep environments up-to-date. The available trigger types are _Manual_ and _Auto_. When the _Auto_ trigger type is chosen, the environment will initiate automatically once the image is built. _Manual_ implies that user has to perform deploy manually by clicking the **Deploy** button in the environment menu. Please refer to the [Architecture Scheme of CD Pipeline Operator](https://github.com/epam/edp-cd-pipeline-operator/blob/master/docs/arch.md) page for additional details. + * **Deploy pipeline template** - Choose a predefined blueprint outlining the deployment process for your application. While you have the option to incorporate custom deployment templates by generating a resource of the PipelineTemplate category, you can also opt for one of the preexisting options: with autotests or without. + * **Clean pipeline template** - Choose one of the pre-defined pipelines offered by KubeRocketCI to define the cleanup logic. In case if you have specific requirements to the environment cleanup procedure, you can make up your own cleanup pipeline to use, which will be added to the **Clean Pipeline template** drop-down list. -Click **Edit YAML** in the upper-right corner of the **Create deployment flow** dialog to open the YAML editor and create a deployment flow: +### Quality Gates - ![Edit YAML](../assets/user-guide/environments/deployment-flow-edit-yaml.png "Edit YAML") +On the **Add quality gates** tab, you define the quality control for the Deployment: -Type you pipeline configuration in the YAML format: + * **Quality gate type** - Select the quality gate type: + * Manual - The promoting process should be confirmed in Tekton manually; + * Autotests - The promoting process should be confirmed by the successful passing of the autotests; + * **Autotest** - Select the previously created [autotest](add-autotest.md) name; + * **Autotest branch** - Specify a branch for the autotest; + * **Step name** - Type the step name, which will be displayed in Tekton, for every quality gate. - ![Deployment flow in YAML](../assets/user-guide/environments/edp-portal-yaml-editor.png "Deployment flow in YAML") + :::info Execution sequence + The image promotion and execution of the pipelines depend on the sequence in which the environments are added. + ::: -To edit YAML in the minimal editor, turn on the **Use minimal editor** toggle in the upper-right corner of the **Create CD Pipeline** dialog. +### Review and Create -To save the changes, select the **Save & Apply** button. +Verify the specified parameters and click the **Create environment** button to start the provisioning of the pipeline. ## Related Articles -* [Manage Deployment Flows](../user-guide/manage-environments.md) +* [Manage Deployments](../user-guide/manage-environments.md) * [Add Quality Gate](../user-guide/add-quality-gate.md) diff --git a/docs/user-guide/add-cluster.md b/docs/user-guide/add-cluster.md index c41eac9449..1d45fdce2a 100644 --- a/docs/user-guide/add-cluster.md +++ b/docs/user-guide/add-cluster.md @@ -30,9 +30,7 @@ Before moving ahead, ensure you have already performed the guidelines outlined i To deploy an application to a remote cluster, follow the steps below: -1. Navigate to **Configuration** -> **Deployment** -> **Clusters** and click the **+ Add cluster** button: - - ![Clusters menu](../assets/user-guide/add_new_cluster.png "Clusters menu") +1. Navigate to **Configuration** -> **Deployment** -> **Clusters** and click the **+ Add cluster** button. 2. In the **Add cluster** window, choose the credentials type and specify the required fields. Click the **Save** button to add the cluster: @@ -55,8 +53,6 @@ To deploy an application to a remote cluster, follow the steps below: The `Cluster Certificate` field is hidden if the `skip TLS verification` option is enabled. ::: - ![Add cluster](../assets/user-guide/krci-portal-add-cluster.png "Add cluster") - @@ -70,44 +66,35 @@ To deploy an application to a remote cluster, follow the steps below: For more details on how to work with clusters integrated using IRSA approach, please refer to the [Deploy Application In Remote Cluster via IRSA](../operator-guide/cd/deploy-application-in-remote-cluster-via-irsa.md) page. ::: - ![Add cluster IRSA](../assets/user-guide/clusters/cluster-irsa-add-cluster.png "Add cluster IRSA") - - - -3. As soon as the cluster is added, switch the KubeRocketCI portal to the **Kubernetes** mode: - - ![Switch to K8s](../assets/user-guide/add-cluster-switch-to-k8s.png "Switch to K8s") - -4. In the **Configuration** section, select **Config maps**: - - ![Config maps](../assets/user-guide/add-cluster-enter-config-maps.png "Config maps") +3. As soon as the cluster is added, open the terminal which has access to the cluster that runs the KubeRocketCI deployment. -5. In the Config maps list, enter the **krci-config** config map: +4. Open the `krci-config` ConfigMap edit menu using the `kubectl edit` command: - ![Edp config](../assets/user-guide/add-cluster-edp-config.png "Edp config") +```bash +kubectl edit ConfigMap krci-config -n krci +``` -6. In the **krci-config** config map, click the pencil icon in the top right corner of the screen: - - ![Edit config map](../assets/user-guide/add-cluster-edit-config-map.png "Edit config map") - -7. In the YAML file, add the `available_clusters` parameter, insert the cluster name, and click **Save & apply**: +5. In the YAML file, add the `available_clusters` parameter, insert the cluster name, and click **Save & apply**: ```yaml title="edp-config.yaml" data: available_clusters: ``` - ![Add new parameter](../assets/user-guide/add-available-clusters.png "Add new parameter") +6. Ensure the `available_clusters` parameter is added into the config map: -8. Ensure the `available_clusters` parameter is added into the config map: +``` +kubectl get ConfigMap krci-config -n krci -o yaml +``` - ![Check added parameter](../assets/user-guide/add-cluster-check-parameter.png "Check added parameter") +## Integrate ArgoCD with External Cluster +To integrate ArgoCD with an external cluster, you need to register the target cluster’s credentials with ArgoCD so that ArgoCD can securely connect to and manage resources in that cluster. This process typically involves creating a Kubernetes Secret in the ArgoCD namespace containing the cluster connection configuration. Depending on your platform and security requirements, authentication can be configured via a static token or by using an AWS IAM Role for Service Accounts (IRSA). -## Integrate ArgoCD with External Cluster +Choose the configuration method that matches your external cluster's authentication mechanism and follow the relevant steps below to prepare your cluster for use with ArgoCD. " server: "https://EXAMPLED539D4633E53DE1B71EXAMPLE.gr7..eks.amazonaws.com" ``` - @@ -201,54 +187,13 @@ To deploy an application to a remote cluster, follow the steps below: -After applying the configuration, you can verify the cluster connection `ArgoCD` -> `Settings` -> `Clusters` -> ``: - - ![ArgoCD cluster IRSA status](../assets/user-guide/clusters/cluster-irsa-argocd-status.png "ArgoCD cluster IRSA status") +After applying the configuration, you can verify the cluster connection `ArgoCD` -> `Settings` -> `Clusters` -> ``. ## Deploy application on new cluster -### Create Deployment Flow - -To create a deployment flow, follow the steps below: - -1. Navigate to the **Deployment Flows** tab and click the **+ Create Deployment Flow** button. - -2. The **Enter name** tab of the **Create Deployment Flow**: - - ![Create deployment flow](../assets/user-guide/clusters/add-df.png "Create deployment flow") - -1. Enter the deployment flow name that will be displayed in the Deployment Flows list. Enter at least two characters, use the lower-case letters, numbers, and dashes. - -2. Click the **Next** button to move onto the **Add applications** tab. - - :::note - The namespace created by the environment has the following pattern combination: **[KubeRocketCI namespace]-[environment name]-[stage name]**. - Please be aware that the namespace length should not exceed 63 symbols. - ::: - -3. The Component tab of the Environments menu is presented below: - - ![Create deployment flow](../assets/user-guide/clusters/create-deployment-flow.png "Create deployment flow") - -4. Click the Create button to finish deployment flow configuration and proceed with configuring environment. - -5. On the Environments menu, click the Create Environment button. - -6. The Configure Stage tab of the Create Stage menu is presented below: - - ![Create environment](../assets/user-guide/clusters/create-environment.png "Create environment") - -Set the proper cluster options: - - * **Cluster** - Choose the `` to deploy the stage in; - * **Stage name** - Enter the stage name; - * **Description** - Enter the description for this stage; - -7. Click the Next button to move onto the Add quality gates tab. - -8. Click the Create button to start the provisioning of the pipeline. cluster-irsa-krci-deployed-application.png +To create a Deployment with an Environment, follow the instructions specified in the [Add Deployment](./add-cd-pipeline.md) page. - ![Environment overview](../assets/user-guide/clusters/env-overview.png "Environment overview") +When creating an Environment, specify your new cluster name in the **Cluster** field. ## Related Articles diff --git a/docs/user-guide/add-git-server.md b/docs/user-guide/add-git-server.md index c83ca5712b..967c907f36 100644 --- a/docs/user-guide/add-git-server.md +++ b/docs/user-guide/add-git-server.md @@ -48,15 +48,11 @@ For [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/create-an-api * Click the profile account and navigate to **Settings** -> **Developer Settings**. * Select *Personal access tokens (classic)* and generate a new token with the following parameters: - ![Repo permissions](../assets/operator-guide/github-scopes-1.png "Repo permissions") :::note The access below is required for the codebase operator to setup hooks. ::: - ![Admin:repo permission](../assets/operator-guide/github-scopes-2.png "Admin:repo permission") - ![Admin:org permission](../assets/operator-guide/github-scopes-4.png "Admin:org permission") - ![User permission](../assets/operator-guide/github-scopes-3.png "User permission") :::warning Make sure to save a new personal access token because it won't be displayed later. @@ -72,7 +68,6 @@ For [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/create-an-api * Choose a name and an optional expiry date for the token. * In the **Scopes** block, select the **api** scope for the token. - ![Personal access tokens](../assets/operator-guide/scopes.png "Personal access tokens") * Click the **Create personal access token** button. @@ -88,7 +83,6 @@ For [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/create-an-api * Choose a role: *Owner* or *Maintainer*. * In the **Scopes** block, select the *api* scope for the token. - ![Project access tokens](../assets/operator-guide/scopes-project.png "Project access tokens") * Click the **Create project access token** button. @@ -103,15 +97,12 @@ For [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/create-an-api * In the **API tokens** section, click the **Create and manage API tokens** button. * In the opened **API tokens** page, click the **Create API token with scopes** button. - ![Create API token](../assets/operator-guide/git-servers/bitbucket-create-api-token.png "Create API token") * In the **Name and expiry** section, provide a name for the token and set the desired expiration period. - ![Name and expiry](../assets/operator-guide/git-servers/bitbucket-name-and-expiry.png "Name and expiry") * In the **Select app** section, choose the "Bitbucket" option as API token app. - ![Select app](../assets/operator-guide/git-servers/bitbucket-select-app.png "Select app") * In the **Select scopes** section, select the required scopes for the token. The following scopes are required for KubeRocketCI integration: @@ -122,15 +113,12 @@ For [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/create-an-api - `read:webhook:bitbucket` - to read webhook configurations. - `write:webhook:bitbucket` - to create and manage webhooks. - ![Select scopes](../assets/operator-guide/git-servers/bitbucket-select-scopes.png "Select scopes") * In the **Create token** section, verify the provided information and click the **Create token** button. - ![Create token](../assets/operator-guide/git-servers/bitbucket-create-token.png "Create token") * Copy the generated token and store it securely, as it will not be displayed again. - ![Copy token](../assets/operator-guide/git-servers/bitbucket-copy-token.png "Copy token") @@ -147,11 +135,21 @@ For [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/create-an-api To enable integration with the selected VCS, it is necessary to add a new Git Server in KubeRocketCI portal. - Navigate to the **Configuration** section and select the **Version Control System** tab in the left sidebar. Click the **Add Git Server** button and fill in the following fields in the opened dialog: + Navigate to the **Configuration** section and select the **Git Servers** under **Version Control System**. Click the **Add Git Server** button and fill in the following fields in the opened dialog: - ![VCS Integration in KubeRocketCI portal](../assets/operator-guide/github_integration.png "GitHub integration") + * **Git provider** – select the Git hosting service: GitHub, GitLab, or Bitbucket. + * **Name** – a unique name for this Git Server integration (e.g., `my-github` or `company-gitlab`). Used to identify the server when creating codebases. + * **Host** – the base URL of your Git server (e.g., `https://github.com`, `https://gitlab.com`, or your self-hosted GitLab/GitHub/Bitbucket URL). + * **User** – the username or account name used to access the Git server (e.g., your GitHub username or GitLab user name). + * **SSH port** – the port used for SSH connections to the Git server. Default is usually `22`; change only if your server uses a different SSH port. + * **HTTPS port** – the port used for HTTPS connections. Default is usually `443`; change only if your server uses a different HTTPS port. + * **Override WebHook URL** – (optional) a custom URL where the Git server will send webhook events. Leave empty to use the default KubeRocketCI webhook endpoint. See [Advanced Configuration: Using a Custom Webhook URL](#advanced-configuration-using-a-custom-webhook-url) for details. + * **Skip Webhook SSL Verification** – (optional) enable this to skip TLS/SSL verification for webhook requests (e.g., for self-signed certificates in development). Not recommended for production. + * **Disable Tekton Resources** – (optional) enable this to prevent KubeRocketCI from creating Tekton pipeline resources (e.g., Pipelines, Tasks) for this Git server. Use when you manage Tekton resources externally. + * **Private SSH Key** – the content of the private SSH key (the one that corresponds to the public key you added to GitHub/GitLab/Bitbucket). Paste the full key including the `-----BEGIN OPENSSH PRIVATE KEY-----` and `-----END OPENSSH PRIVATE KEY-----` lines. + * **Token** – the token you generated in step 2. -As a result, you will be able to create codebases using an integrated Version Control System. + Click **Save** to create the Git Server. As a result, you will be able to create codebases using an integrated Version Control System. ## Bitbucket Default Branch Management @@ -163,11 +161,9 @@ To change the default branch from `master` to desired branch in Bitbucket, follo * Navigate to the repository where the default branch needs to be changed. * In the left sidebar menu, select **Repository Settings**. - ![Repository Settings](../assets/operator-guide/git-servers/repository-settings.png "Repository settings") * Proceed to the **Advanced** section. Locate the **Main branch** field and select your desired branch to set it as the default. - ![Default branch](../assets/operator-guide/git-servers/default-branch.png "Default branch") * Click **Save changes** to apply your modifications. diff --git a/docs/user-guide/add-infrastructure.md b/docs/user-guide/add-infrastructure.md index bc6c53df91..bb39594fbd 100644 --- a/docs/user-guide/add-infrastructure.md +++ b/docs/user-guide/add-infrastructure.md @@ -1,9 +1,7 @@ --- - title: "Add Infrastructure" sidebar_label: "Add Infrastructure" description: "Learn how to add, clone, and import infrastructure projects in KubeRocketCI, automating resource creation in the cloud for robust development." - --- @@ -13,134 +11,97 @@ description: "Learn how to add, clone, and import infrastructure projects in Kub -KubeRocketCI portal allows you to create an application, clone an existing repository with the application to your Version Control System (VCS), or using an external repository and importing an application to the environment. -When an application is created or cloned, the system automatically generates a corresponding repository within the integrated Version Control System. The functionality of the Infrastructure codebase type is to create resources in cloud provider. You can create an Infrastructure [in YAML](#create-infrastructure-in-yaml) or [via the two-step menu](#create-infrastructure-via-ui) in the dialog. - -To add an infrastructure, navigate to the **Components** section on the navigation bar and click **+ Create component**: - - ![Create new infrastructure](../assets/user-guide/components/components-create-new-codebase.png "Create new infrastructure") - -Once clicked, the **Create new component** dialog will appear. Select **Infrastructure** and click **Next**: - - ![Infrastructure info](../assets/user-guide/components/components-select-type-new-codebase.png) - -Choose one of the strategies and click **Create**: - - ![Select strategy](../assets/user-guide/components/components-select-strategy.png "Select strategy") - -In the **Create new component** menu, select the necessary configuration strategy. The choice will define the parameters you will need to specify: - -* **Create from template** – creates a project on the pattern in accordance with an infrastructure language, a build tool, and a framework. - -* **Import project** - allows using existing VCS repository to integrate with KubeRocketCI. While importing the existing repository, select the Git server from the drop-down list and define the relative path to the repository, such as `epmd-edp/python-python-flask`. - - :::note - In order to use the **Import project** strategy, make sure to adjust it with the [Integrate GitLab/GitHub With Tekton](../user-guide/add-git-server.md) page. - ::: - -* **Clone project** – clones the indicated repository into KubeRocketCI. While cloning the existing repository, it is required to fill in the **Repository URL** field and specify the **Repository credentials** field if needed: - - ![Clone infrastructure](../assets/user-guide/components/infrastructure/infrastructure-clone-infrastructure.png "Clone infrastructure") - -## Create Infrastructure in YAML +KubeRocketCI portal allows you to create an infrastructure project, clone an existing repository with the infrastructure to your Version Control System (VCS), or use an external repository and import an infrastructure to the environment. The Infrastructure codebase type is used to create and manage resources in a cloud provider. When an infrastructure project is created or cloned, the system automatically generates a corresponding repository within the integrated Version Control System. You can create an Infrastructure [in YAML](#create-infrastructure-in-yaml) or [via the dialog](#create-infrastructure-via-ui). -Click **Edit YAML** in the upper-right corner of the **Create Infrastructure** dialog to open the YAML editor and create the Infrastructure. +The **Create Infrastructure** dialog contains four steps: -![Edit YAML](../assets/user-guide/components/infrastructure/infrastructure-yaml-edit.png "Edit YAML") +* Initial Setup +* Git & Project Info +* Build Config +* Review -To edit YAML in the minimal editor, turn on the **Use minimal editor** toggle in the upper-right corner of the **Create Infrastructure** dialog. +To add an infrastructure, navigate to the **Projects** section on the navigation bar and click **+ Create Project**. -To save the changes, select the **Save & Apply** button. +## Initial Setup -## Create Infrastructure via UI +Once clicked, the **Create new project** dialog will appear. In this dialog, you can make a choice: -The **Create Infrastructure** dialog contains the two steps: +* **Select Ready Template** – this option allows you to select a preconfigured, ready-to-go infrastructure template (e.g., Terraform). +* **Custom Configuration** – this option allows you to create any of the supported Project types. In this case, you should select **Infrastructure**. -* The Codebase Info Menu -* The Advanced Settings Menu +Choose one of the strategies and click **Continue**: -### Codebase Info Menu +* **Create** – creates a project on the pattern in accordance with an infrastructure language, a build tool, and a framework. This strategy is recommended for projects that start defining their infrastructure from scratch. -In our example, we will use the **Create from template** strategy. +* **Import** – allows using an existing VCS repository to integrate with KubeRocketCI. While importing the existing repository, select the Git server from the drop-down list and define the relative path to the repository, such as `epmd-edp/terraform-aws-example`. -1. Select all the settings that define how the infrastructure will be added to Git server: +* **Clone** – clones the indicated repository into KubeRocketCI. While cloning the existing repository, it is required to fill in the **Repository URL** field and specify the credentials if needed. - ![Create infrastructure](../assets/user-guide/components/infrastructure/infrastructure-create-infrastructure.png "Create infrastructure") +## Git & Project Info - * **Git server** - the pre-configured server where the component will be hosted. Select one from the drop-down list. Please refer to the [Manage Git Servers](git-server-overview.md) page to learn how to create the one. - * **Repository name** - the relative path to the repository, such as `epmd-edp/python-python-flask`. - * **Component name** - the name of the infrastructure. Must be at least two characters using the lower-case letters, numbers and inner dashes. - * **Description** - brief and concise description that explains the purpose of the infrastructure. - * **Empty project** - check this box to create a infrastructure with an empty repository. The empty repository option is available only for the **Create from template** strategy. +In our example, we will use the **Create** strategy: -2. Specify the infrastructure language properties: +Select all the settings that define how the infrastructure will be added to the Git server: - * **Infrastructure code language** - defines the code language with its supported frameworks. - * **Language version/framework** - defines the specific framework or language version of the infrastructure. The field depends on the selected code language. - * **Build Tool** - allows to choose the build tool to use. A set tools and can be changed in accordance with the selected code language. +* **Git server** – the pre-configured server where the component will be hosted. Select one from the drop-down list. Please refer to the [Manage Git Servers](git-server-overview.md) page to learn how to create one. +* **Git URL Path** – the relative path to the Git repository where the codebase will be created (e.g., `epmd-edp` or `my-github-username`). +* **Project name** – the name of the infrastructure. Must be at least two characters using lower-case letters, numbers, and inner dashes. +* **Default Branch** – the default branch the Project will be created with. The default branch cannot be deleted. +* **Description** – brief and concise description that explains the purpose of the infrastructure. +* **Private** – by default, all created Projects have private visibility settings in your Git account. Uncheck this option to create a public Git repository. +* **Empty project** – check this box to create an infrastructure with an empty repository. The empty repository option is available only for the **Create** strategy. -### Advanced Settings Menu +## Build Config -In the **Advanced Settings** menu, specify the branch options and define the Jira settings: +Specify the infrastructure language and versioning properties: - ![Advanced settings](../assets/user-guide/components/components-specify-advanced-settings.png "Advanced settings") +* **Code Language** – defines the code language with its supported frameworks. For infrastructure, **Terraform** is commonly used; other options may be available depending on the platform configuration. +* **Language version/framework** – defines the specific framework or language version of the infrastructure. The field depends on the selected code language. +* **Build Tool** – allows you to choose the build tool to use. The set of tools can be changed in accordance with the selected code language. -Follow the instructions below to fill in the fields of the **Advanced Setting** menu: - -* **Default branch** - the name of the branch where you want the development to be performed. +* **Codebase versioning type** – defines how the infrastructure tag will be changed once the new image version is built. There are two versioning types: + * **default**: Using the `default` versioning type, to specify the version of the current artifacts, images, and tags in the Version Control System, a developer should navigate to the corresponding file and change the version **manually**. + * **semver**: Using the `semver` versioning type, a developer indicates the version number from which all artifacts will be versioned and, as a result, **automatically** registered in the corresponding file. When selecting the `semver` versioning type, extra fields will appear; type the version number from which you want the artifacts to be versioned. :::note - The default branch cannot be deleted. + The **Start Version From** field should be filled out in compliance with the semantic versioning rules, e.g. 1.2.3 or 10.10.10. Please refer to the [Semantic Versioning](https://semver.org/) page for details. ::: -* **Codebase versioning type** - defines how will the infrastructure tag be changed once the new image version is built. There are two versioning types: - * **default**: Using the `default` versioning type, in order to specify the version of the current artifacts, images, and tags in the Version Control System, a developer should navigate to the corresponding file and change the version **manually**. - * **semver**: Using the `semver` versioning type, a developer indicates the version number from which all the artifacts will be versioned and, as a result, **automatically** registered in the corresponding file (e.g. pom.xml). When selecting the `semver` versioning type, the extra fields will appear, type the version number from which you want the artifacts to be versioned: - - ![Semver versioning](../assets/user-guide/components/components-edp-versioning.png "Semver versioning") - - :::note - The **Start Version From** field should be filled out in compliance with the semantic versioning rules, e.g. 1.2.3 or 10.10.10. Please refer to the [Semantic Versioning](https://semver.org/) page for details. - ::: +* **Specify the pattern to validate a commit message** – the regular expression used to indicate the pattern that is followed on the project to validate a commit message in the code review pipeline. An example of the pattern: `^[PROJECT_NAME-d{4}]:.*$`. -* **Specify the pattern to validate a commit message** - the regular expression used to indicate the pattern that is followed on the project to validate a commit message in the code review pipeline. An example of the pattern: `^[PROJECT_NAME-d{4}]:.*$`. - - ![JIRA integration](../assets/user-guide/components/components-jira-server.png "JIRA integration") - -* **Integrate with Jira server** - this check box is used in case it is required to connect Jira tickets with the commits and have a respective label in the **Fix Version** field. +* **Integrate with Jira server** – this check box is used in case it is required to connect Jira tickets with the commits and have a respective label in the **Fix Version** field. :::note To adjust the Jira integration functionality, first apply the necessary changes described on the [Adjust Jira Integration](../operator-guide/project-management-and-reporting/jira-integration.md) page. ::: -* **Jira Server** - the integrated Jira server with related Jira tasks. - -* **Specify the pattern to find a Jira ticket number in a commit message** - based on this pattern, the value from KubeRocketCI will be displayed in Jira. +* **Jira Server** – the integrated Jira server with related Jira tasks. - ![Mapping field name](../assets/user-guide/components/components-jira-advanced-mapping.png "Mapping fields") +* **Specify the pattern to find a Jira ticket number in a commit message** – based on this pattern, the value from KubeRocketCI will be displayed in Jira. -* **Mapping field name** - the section where the additional Jira fields are specified the names of the Jira fields that should be filled in with attributes from KubeRocketCI: - - * Select the name of the field in a Jira ticket. The available fields are the following: _Fix Version/s_, _Component/s_ and _Labels_. +* **Mapping field name** – the section where the additional Jira fields are specified, i.e. the names of the Jira fields that should be filled in with attributes from KubeRocketCI: + * Select the name of the field in a Jira ticket. The available fields are: _Fix Version/s_, _Component/s_, and _Labels_. * Click the **Add** button to add the mapping field name. + * Enter the Jira pattern for the field name: - * Enter Jira pattern for the field name: - - * For the **Fix Version/s** field, select the **EDP_VERSION** variable that represents an EDP upgrade version, as in _2.7.0-SNAPSHOT_.Combine variables to make the value more informative. For example, the pattern **EDP_VERSION-EDP_COMPONENT** will be displayed as _2.7.0-SNAPSHOT-nexus-operator_ in Jira. - * For the **Component/s** field select the **EDP_COMPONENT** variable that defines the name of the existing repository. For example, _nexus-operator_. - * For the **Labels** field select the **EDP_GITTAG** variable that defines a tag assigned to the commit in Git Hub. For example, _build/2.7.0-SNAPSHOT.59_. + * For the **Fix Version/s** field, select the **EDP_VERSION** variable that represents a KubeRocketCI upgrade version, as in _2.7.0-SNAPSHOT_. Combine variables to make the value more informative. For example, the pattern **EDP_VERSION-EDP_COMPONENT** will be displayed as _2.7.0-SNAPSHOT-nexus-operator_ in Jira. + * For the **Component/s** field, select the **EDP_COMPONENT** variable that defines the name of the existing repository. For example, _nexus-operator_. + * For the **Labels** field, select the **EDP_GITTAG** variable that defines a tag assigned to the commit in GitHub. For example, _build/2.7.0-SNAPSHOT.59_. * Click the bin icon to remove the Jira field name. -Click the **Apply** button to add the infrastructure to the Components list. +## Review and Create + +The **Review and Create** window allows you to ensure the infrastructure configuration suits your needs and verify you entered the specifications correctly. :::note - After the complete adding of the application, inspect the [Manage Infrastructures](infrastructure.md) page to learn how you can operate with infrastructure codebase types. +After the complete adding of the infrastructure, inspect the [Manage Infrastructures](infrastructure.md) page to learn how you can operate infrastructure codebase types. ::: ## Related Articles -* [Application Overview](application.md) -* [Add CD Pipelines](add-cd-pipeline.md) +* [Manage Infrastructures](infrastructure.md) +* [Add CD Pipeline](add-cd-pipeline.md) * [Adjust Jira Integration](../operator-guide/project-management-and-reporting/jira-integration.md) +* [Manage Git Servers](git-server-overview.md) diff --git a/docs/user-guide/add-library.md b/docs/user-guide/add-library.md index 11e5c0684d..415fcf06f3 100644 --- a/docs/user-guide/add-library.md +++ b/docs/user-guide/add-library.md @@ -1,11 +1,8 @@ --- - title: "Add Library" -description: "Discover how to add and manage libraries in KubeRocketCI, from cloning repositories to leveraging external sources for improved development." sidebar_label: "Add Library" - +description: "Discover how to add and manage libraries in KubeRocketCI, from cloning repositories to leveraging external sources for improved development." --- - # Add Library @@ -14,152 +11,117 @@ sidebar_label: "Add Library" -KubeRocketCI portal allows you to create a library, clone an existing repository with the library to your Version Control System (VCS), or using an external repository and importing a library to the environment. -When a library is created or cloned, the system automatically generates a corresponding repository within the integrated VCS. You can create a library [in YAML](#create-library-in-yaml) or [via the two-step menu](#create-library-via-ui) in the dialog. - -To add a library, navigate to the **Components** section on the navigation bar and click **+ Create component**: - - ![Create new library](../assets/user-guide/components/components-create-new-codebase.png "Create new library") - -Once clicked, the **Create new component** dialog will appear. Select **Library** and click **Next**: - - ![Edit YAML](../assets/user-guide/components/components-select-type-new-codebase.png "Create new component menu") - -Choose one of the strategies and click **Create**: - - ![Select strategy](../assets/user-guide/components/components-select-strategy.png "Select strategy") - -In the **Create new component** menu, select the necessary configuration strategy. The choice will define the parameters you will need to specify: - -* **Create from template** – creates a project on the pattern in accordance with a library language, a build tool, and a framework. - -* **Import project** - allows using existing VCS repository to integrate with KubeRocketCI. While importing the existing repository, select the Git server from the drop-down list and define the relative path to the repository, such as `epmd-edp/python-python-flask`. - - :::note - In order to use the **Import project** strategy, make sure to adjust it with the [Integrate GitLab/GitHub With Tekton](../user-guide/add-git-server.md) page. - ::: - -* **Clone project** – clones the indicated repository into KubeRocketCI. While cloning the existing repository, it is required to fill in the **Repository URL** field and specify the **Repository credentials** field if needed: - - ![Clone library](../assets/user-guide/components/library/library-clone-library.png "Clone library") - -## Create Library in YAML - -Click **Edit YAML** in the upper-right corner of the **Create Library** dialog to open the YAML editor and create the library: - - ![Edit YAML](../assets/user-guide/components/library/library-yaml-edit.png "Edit YAML") - -To edit YAML in the minimal editor, turn on the **Use minimal editor** toggle in the upper-right corner of the **Create Library** dialog. - -To save the changes, select the **Save & Apply** button. +KubeRocketCI portal allows you to create a library, clone an existing repository with the library to your Version Control System (VCS), or use an external repository and import a library to the environment. When a library is created or cloned, the system automatically generates a corresponding repository within the integrated Version Control System. You can create a Library [in YAML](#create-library-in-yaml) or [via the dialog](#create-library-via-ui). -## Create Library via UI +The **Create Library** dialog contains four steps: -The **Create Library** dialog contains the two steps: +* Initial Setup +* Git & Project Info +* Build Config +* Review -* The Codebase Info Menu -* The Advanced Settings Menu +To add a library, navigate to the **Projects** section on the navigation bar and click **+ Create Project**. -### The Codebase Info Menu +## Initial Setup -In our example, we will use the **Create from template** strategy: +Once clicked, the **Create new project** dialog will appear. In this dialog, you can make a choice: - ![Create library](../assets/user-guide/components/library/library-create-new-library.png "Create library") +* **Select Ready Template** – this option allows you to select a preconfigured, ready-to-go library (e.g., shared pipeline or Terraform module). +* **Custom Configuration** – this option allows you to create any of the supported Project types. In this case, you should select **Library**. -1. Select all the settings that define how the library will be added to Git server: +Choose one of the strategies and click **Continue**: - * **Git server** - the pre-configured server where the component will be hosted. Select one from the drop-down list. Please refer to the [Manage Git Servers](git-server-overview.md) page to learn how to create the one. - * **Repository name** - the relative path to the repository, such as `epmd-edp/python-python-flask`. - * **Component name** - the name of the library. Must be at least two characters using the lower-case letters, numbers and inner dashes. - * **Description** - brief and concise description that explains the purpose of the library. - * **Empty project** - check this box to create a library with an empty repository. The empty repository option is available only for the **Create from template** strategy. +* **Create** – creates a project on the pattern in accordance with a library language, a build tool, and a framework. This strategy is recommended for projects that start developing their libraries from scratch. -2. Specify the library language properties: +* **Import** – allows using an existing VCS repository to integrate with KubeRocketCI. While importing the existing repository, select the Git server from the drop-down list and define the relative path to the repository, such as `epmd-edp/python-python-flask`. - * **Library code language** - defines the code language with its supported frameworks: +* **Clone** – clones the indicated repository into KubeRocketCI. While cloning the existing repository, it is required to fill in the **Repository URL** field and specify the credentials if needed. - * Java – selecting specific Java version (17, 21, and 25 are available; Java 8 and 11 deprecated since v3.12). - * JavaScript - selecting JavaScript allows using the React, Vue, Angular, Express, and Next.js frameworks. - * Python - selecting Python allows using the Python v.3.8, FastAPI, Flask. - * Groovy-pipeline - selecting Groovy-pipeline allows having the ability to customize a stages logic. - * Terraform - selecting Terraform allows using the Terraform different versions via the **Terraform version manager** ([tfenv](https://github.com/tfutils/tfenv#usage)). - KubeRocketCI supports all the actions available in Terraform, thus providing the ability to modify the virtual infrastructure and launch some checks with the help of linters. - For details, please refer to the [Use Terraform Library in KubeRocketCI](../operator-guide/ci/ci-pipeline-terraform.md) page. - * Rego - this option allows using Rego code language with an Open Policy Agent (OPA) Library. - * Container - this option allows using the Kaniko tool for building the container images from a Dockerfile. - * Helm - this option allows using the [chart testing lint](https://github.com/helm/chart-testing) (Pipeline) for Helm charts or using Helm chart as a set of other Helm charts organized according to the [example](https://github.com/argoproj/argo-helm/tree/main). - * C# - selecting C# allows using .Net v.3.1 and .Net v.6.0. - * Other - selecting Other allows extending the default code languages when creating a codebase with the Clone/Import strategy. +## Git & Project Info - :::info - The **Create** strategy does not allow to customize the default code language set. - ::: +In our example, we will use the **Create** strategy: - * **Language version/framework** - defines the specific framework or language version of the library. The field depends on the selected code language. - * **Build Tool** - allows to choose the build tool to use. A set tools and can be changed in accordance with the selected code language. +Select all the settings that define how the library will be added to the Git server: -Click the **Next** button to switch to the next menu. +* **Git server** – the pre-configured server where the component will be hosted. Select one from the drop-down list. Please refer to the [Manage Git Servers](git-server-overview.md) page to learn how to create one. +* **Git URL Path** – the relative path to the Git repository where the codebase will be created (e.g., `epmd-edp` or `my-github-username`). +* **Project name** – the name of the library. Must be at least two characters using lower-case letters, numbers, and inner dashes. +* **Default Branch** – the default branch the Project will be created with. The default branch cannot be deleted. +* **Description** – brief and concise description that explains the purpose of the library. +* **Private** – by default, all created Projects have private visibility settings in your Git account. Uncheck this option to create a public Git repository. +* **Empty project** – check this box to create a library with an empty repository. The empty repository option is available only for the **Create** strategy. -### The Advanced Settings Menu +## Build Config -In the Advanced Settings menu, specify the branch options and define the Jira settings: +Specify the library language and versioning properties: - ![Advanced settings](../assets/user-guide/components/components-specify-advanced-settings.png "Advanced settings") +* **Code Language** – defines the code language with its supported frameworks: -* **Default branch** - the name of the branch where you want the development to be performed. + * Java – selecting a specific Java version (17, 21, and 25 are available; Java 8 and 11 have been deprecated starting from KubeRocketCI version 3.12). + * JavaScript – selecting JavaScript allows using React, Vue, Angular, Express, and Next.js frameworks. + * Python – selecting Python allows using Python v.3.8, FastAPI, and Flask frameworks. + * Groovy-pipeline – selecting Groovy-pipeline allows customizing stage logic. + * Terraform – selecting Terraform allows using different Terraform versions via the **Terraform version manager** ([tfenv](https://github.com/tfutils/tfenv#usage)). KubeRocketCI supports all actions available in Terraform. For details, please refer to the [Use Terraform Library in KubeRocketCI](../operator-guide/ci/ci-pipeline-terraform.md) page. + * Rego – this option allows using Rego code language with an Open Policy Agent (OPA) Library. + * Container – this option allows using the Kaniko tool for building container images from a Dockerfile. + * Helm – this option allows using [chart testing lint](https://github.com/helm/chart-testing) for Helm charts or using a Helm chart as a set of other Helm charts. + * C# – selecting C# allows using .Net v.3.1 and .Net v.6.0 frameworks. + * Other – selecting Other allows extending the default code languages when creating a codebase with the Clone/Import strategy. :::note - The default branch cannot be deleted. + The **Create from template** strategy does not allow customizing the default code language set. ::: -* **Codebase versioning type** - defines how will the library tag be changed once the new image version is built. There are two versioning types: - * **default**: Using the `default` versioning type, in order to specify the version of the current artifacts, images, and tags in the Version Control System, a developer should navigate to the corresponding file and change the version **manually**. - * **semver**: Using the `semver` versioning type, a developer indicates the version number from which all the artifacts will be versioned and, as a result, **automatically** registered in the corresponding file (e.g. pom.xml). When selecting the `semver` versioning type, the extra fields will appear, type the version number from which you want the artifacts to be versioned: +* **Language version/framework** – defines the specific framework or language version of the library. The field depends on the selected code language. +* **Build Tool** – allows you to choose the build tool to use. The set of tools can be changed in accordance with the selected code language. - ![Semver versioning](../assets/user-guide/components/components-edp-versioning.png "Semver versioning") + :::note + The **Select Build Tool** field disposes of the default tools and can be changed in accordance with the selected code language. + ::: - :::note - The **Start Version From** field should be filled out in compliance with the semantic versioning rules, e.g. 1.2.3 or 10.10.10. Please refer to the [Semantic Versioning](https://semver.org/) page for details. - ::: +* **Codebase versioning type** – defines how the library tag will be changed once the new image version is built. There are two versioning types: + * **default**: Using the `default` versioning type, to specify the version of the current artifacts, images, and tags in the Version Control System, a developer should navigate to the corresponding file and change the version **manually**. + * **semver**: Using the `semver` versioning type, a developer indicates the version number from which all artifacts will be versioned and, as a result, **automatically** registered in the corresponding file (e.g. pom.xml). When selecting the `semver` versioning type, extra fields will appear; type the version number from which you want the artifacts to be versioned. -* **Specify the pattern to validate a commit message** - the regular expression used to indicate the pattern that is followed on the project to validate a commit message in the code review pipeline. An example of the pattern: `^[PROJECT_NAME-d{4}]:.*$`. + :::note + The **Start Version From** field should be filled out in compliance with the semantic versioning rules, e.g. 1.2.3 or 10.10.10. Please refer to the [Semantic Versioning](https://semver.org/) page for details. + ::: - ![Integrate with Jira server](../assets/user-guide/components/components-jira-server.png "Integrate with Jira server") +* **Specify the pattern to validate a commit message** – the regular expression used to indicate the pattern that is followed on the project to validate a commit message in the code review pipeline. An example of the pattern: `^[PROJECT_NAME-d{4}]:.*$`. -* **Integrate with Jira server** - this check box is used in case it is required to connect Jira tickets with the commits -and have a respective label in the **Fix Version** field. +* **Integrate with Jira server** – this check box is used in case it is required to connect Jira tickets with the commits and have a respective label in the **Fix Version** field. :::note To adjust the Jira integration functionality, first apply the necessary changes described on the [Adjust Jira Integration](../operator-guide/project-management-and-reporting/jira-integration.md) page. ::: -* **Jira Server** - the integrated Jira server with related Jira tasks. +* **Jira Server** – the integrated Jira server with related Jira tasks. -* **Specify the pattern to find a Jira ticket number in a commit message** - based on this pattern, the value from KubeRocketCI will be displayed in Jira. +* **Specify the pattern to find a Jira ticket number in a commit message** – based on this pattern, the value from KubeRocketCI will be displayed in Jira. - ![Mapping fields](../assets/user-guide/components/components-jira-advanced-mapping.png "Mapping fields") - -* **Mapping field name** - the section where the additional Jira fields are specified the names of the Jira fields that should be filled in with attributes from KubeRocketCI: - - * Select the name of the field in a Jira ticket. The available fields are the following: _Fix Version/s_, _Component/s_ and _Labels_. +* **Mapping field name** – the section where the additional Jira fields are specified, i.e. the names of the Jira fields that should be filled in with attributes from KubeRocketCI: + * Select the name of the field in a Jira ticket. The available fields are: _Fix Version/s_, _Component/s_, and _Labels_. * Click the **Add** button to add the mapping field name. + * Enter the Jira pattern for the field name: - * Enter Jira pattern for the field name: - - * For the **Fix Version/s** field, select the **EDP_VERSION** variable that represents an EDP upgrade version, as in _2.7.0-SNAPSHOT_.Combine variables to make the value more informative. For example, the pattern **EDP_VERSION-EDP_COMPONENT** will be displayed as _2.7.0-SNAPSHOT-nexus-operator_ in Jira. - * For the **Component/s** field select the **EDP_COMPONENT** variable that defines the name of the existing repository. For example, _nexus-operator_. - * For the **Labels** field select the **EDP_GITTAG** variable that defines a tag assigned to the commit in Git Hub. For example, _build/2.7.0-SNAPSHOT.59_. + * For the **Fix Version/s** field, select the **EDP_VERSION** variable that represents a KubeRocketCI upgrade version, as in _2.7.0-SNAPSHOT_. Combine variables to make the value more informative. For example, the pattern **EDP_VERSION-EDP_COMPONENT** will be displayed as _2.7.0-SNAPSHOT-nexus-operator_ in Jira. + * For the **Component/s** field, select the **EDP_COMPONENT** variable that defines the name of the existing repository. For example, _nexus-operator_. + * For the **Labels** field, select the **EDP_GITTAG** variable that defines a tag assigned to the commit in GitHub. For example, _build/2.7.0-SNAPSHOT.59_. * Click the bin icon to remove the Jira field name. -Click the **Create** button to add the library to the Components list. +## Review and Create + +The **Review and Create** window allows you to ensure the library configuration suits your needs and verify you entered the specifications correctly. -After the complete adding of the library, inspect the [Library Overview](library.md) page to learn how you can operate applications. +:::note +After the complete adding of the library, inspect the [Manage Libraries](library.md) page to learn how you can operate libraries. +::: ## Related Articles * [Manage Libraries](library.md) * [Add CD Pipeline](add-cd-pipeline.md) * [Adjust Jira Integration](../operator-guide/project-management-and-reporting/jira-integration.md) -* [Manage Git Providers](../user-guide/add-git-server.md) +* [Manage Git Servers](git-server-overview.md) diff --git a/docs/user-guide/add-quality-gate.md b/docs/user-guide/add-quality-gate.md index 29c75b8ae2..6ac394b61a 100644 --- a/docs/user-guide/add-quality-gate.md +++ b/docs/user-guide/add-quality-gate.md @@ -120,17 +120,14 @@ Before running the quality gate, first of all, ensure that the environment has d 1. Check the CD pipeline status. To do this, open the created CD pipeline, select `Image stream version`, click `DEPLOY` button and wait until `Applications`, `Health` and `Sync` statuses become `green`. This implies that the application is successfully deployed and ready to run the quality gate. - ![CD pipeline stage overview](../assets/user-guide/qg_cd_status.png "CD pipeline stage overview") 2. Select the name-of-quality-gate of `Quality gates` from the drop-down list and click the `RUN` button.
The execution process should be started in the `Pipelines` menu: - ![Quality gate pipeline status](../assets/user-guide/qg_stage_status.png "Quality gate pipeline status") ## Add Stage for Quality Gate For a better understanding of this section, please read the documentation about how to [add a new stage for quality gate](add-cd-pipeline.md). The scheme below illustrates two approaches of adding quality gates: - ![Quality gate promote a scheme](../assets/user-guide/qg_promote_shema.png "Types of adding quality gate") * The first type of adding a quality gate is about adding the specific quality gate to the specific pipeline stage. diff --git a/docs/user-guide/application-and-pipeline-statuses.md b/docs/user-guide/application-and-pipeline-statuses.md index 6ad1a8b668..6f42ac62e2 100644 --- a/docs/user-guide/application-and-pipeline-statuses.md +++ b/docs/user-guide/application-and-pipeline-statuses.md @@ -62,10 +62,6 @@ The pipeline status represents the current state of the pipeline. The following | Failed | The pipeline has encountered an error, causing execution to stop before completion. Some tasks may have failed or been skipped. | | Unknown | The pipeline status cannot be determined. In most cases this status indicates some errors with starting pipeline. | -Example of pipeline status is provided below: - -![Pipeline Status](../assets/user-guide/application-statuses/pipeline-status.png "Pipeline Status") - ### Application Status :::note @@ -76,10 +72,6 @@ After the deployment of an application, KubeRocketCI provides an application sta The application status can be found under the **Applications** tab for the appropriate environment. These statuses are updated in real-time and provide a quick overview of the application health and sync status regarding the Argo CD application. -Example of application statuses is provided below: - -![Application Statuses](../assets/user-guide/application-statuses/application-statuses.png "Application Statuses") - ## Use Cases :::note @@ -96,29 +88,19 @@ Suppose we have `fast-api` application to be deployed in the `demo-dev` environm 1. Navigate to the KubeRocketCI portal. -2. In the left sidebar, navigate to the **Deployment Flows** tab and select the **demo** (or any other appropriate) environment where the application should be deployed. - - ![Select Environment](../assets/user-guide/application-statuses/select-environment.png "Select Environment") +2. In the left sidebar, navigate to the **Deployments** tab and select the **demo** (or any other appropriate) environment where the application should be deployed. 3. Select the **dev** environment and navigate to the **Applications** tab. Click on the **Configure Deploy** button to deploy the application. - ![Select Applications](../assets/user-guide/application-statuses/select-applications.png "Select Applications") - 4. Choose the appropriate application version and click on the **Start Deploy** button to deploy the application. - ![Start Deploy](../assets/user-guide/application-statuses/start-deploy.png "Start Deploy") - 5. After the deployment process is started, navigate to the **Pipelines** tab to monitor the pipeline status. Ensure that the pipeline status is `Succeeded`. - ![Pipeline Status](../assets/user-guide/application-statuses/pipeline-status.png "Pipeline Status") - - This status indicates that the pipeline has completed successfully. All tasks have been executed without errors. Application is now deployed and synced. + This status indicates that the pipeline has completed successfully. All tasks have been executed without errors. Application is now deployed and synced. -6. To ensure that the application is healthy and synced, navigate back to the **dev** environment of the **demo** deployment flow. Under the **Applications** tab, the application status should be `Healthy` and `Synced`. +6. To ensure that the application is healthy and synced, navigate back to the **dev** environment of the **demo** deployment. Under the **Applications** tab, the application status should be `Healthy` and `Synced`. - ![Application Statuses](../assets/user-guide/application-statuses/application-status.png "Application Statuses") - - These statuses indicate that the Argo CD application is healthy and all resources are successfully deployed and synced. + These statuses indicate that the Argo CD application is healthy and all resources are successfully deployed and synced. 7. Also, to verify the application status in Argo CD, navigate to the Argo CD UI and check the application status. The application should be `Healthy` and `Synced`. @@ -132,9 +114,7 @@ In this scenario, we will cover the status of an application that is out of sync Suppose we have successfully deployed the `fast-api` application in the `demo-dev` environment. Follow the steps below to make the application out of sync: -1. In KubeRocketCI portal, navigate to the **Applications** tab under the **dev** environment of the **demo** deployment flow. Ensure that the application status is `Healthy` and `Synced`. - - ![Application Statuses](../assets/user-guide/application-statuses/application-status.png "Application Statuses") +1. In KubeRocketCI portal, navigate to the **Applications** tab under the **dev** environment of the **demo** deployment. Ensure that the application status is `Healthy` and `Synced`. Also, verify the application status in Argo CD. The application should be `Healthy` and `Synced`. @@ -148,11 +128,7 @@ Suppose we have successfully deployed the `fast-api` application in the `demo-de For example, navigate to the Kubernetes section of the KubeRocketCI portal and scale the deployment of the `fast-api` application to 0 replicas. - ![Scale Deployment](../assets/user-guide/application-statuses/scale-deployment.png "Scale Deployment") - -3. After making the changes, navigate back to the **Applications** tab under the **dev** environment of the **demo** deployment flow. The application status should now be `Healthy`, but `OutOfSync`. - - ![OutOfSync Application](../assets/user-guide/application-statuses/out-of-sync-application.png "OutOfSync Application") +3. After making the changes, navigate back to the **Applications** tab under the **dev** environment of the **demo** deployment. The application status should now be `Healthy`, but `OutOfSync`. This status indicates that the application is healthy, but the resources in the cluster differ from the expected state in the Git repository. @@ -172,9 +148,7 @@ In this scenario, we will cover the status of an application that has one or mor Suppose we have successfully deployed the `fast-api` application in the `demo-dev` environment. Follow the steps below to make the application degraded: -1. In KubeRocketCI portal, navigate to the **Applications** tab under the **dev** environment of the **demo** deployment flow. Ensure that the application status is `Healthy` and `Synced`. - - ![Application Statuses](../assets/user-guide/application-statuses/application-status.png "Application Statuses") +1. In KubeRocketCI portal, navigate to the **Applications** tab under the **dev** environment of the **demo** deployment. Ensure that the application status is `Healthy` and `Synced`. Also, verify the application status in Argo CD. The application should be `Healthy` and `Synced`. @@ -184,11 +158,7 @@ Suppose we have successfully deployed the `fast-api` application in the `demo-de For example, navigate to the Kubernetes section of the KubeRocketCI portal and edit the `fast-api` deployment with incorrect service account name (e.g., `fast-api-degraded`). Save the changes to apply the configuration. - ![Edit Deployment](../assets/user-guide/application-statuses/edit-deployment.png "Edit Deployment") - -3. After making the changes, navigate back to the **Applications** tab under the **dev** environment of the **demo** deployment flow. The application status should now be `Progressing` and `OutOfSync`. - - ![Progressing Application](../assets/user-guide/application-statuses/progressing-application.png "Progressing Application") +3. After making the changes, navigate back to the **Applications** tab under the **dev** environment of the **demo** deployment. The application status should now be `Progressing` and `OutOfSync`. 4. Also, verify the application status in Argo CD. The application status should be `Progressing` and `OutOfSync`. @@ -198,7 +168,6 @@ Suppose we have successfully deployed the `fast-api` application in the `demo-de 5. After a few minutes, the application status should change to `Degraded`, indicating that one or more resources in the application have issues or failed to reach a healthy state. - ![Degraded Application](../assets/user-guide/application-statuses/degraded-application.png "Degraded Application") In the Argo CD, the application status will also change to `Degraded`. The resources that have issues will be highlighted in red. diff --git a/docs/user-guide/application.md b/docs/user-guide/application.md index d81381d843..cf089995e4 100644 --- a/docs/user-guide/application.md +++ b/docs/user-guide/application.md @@ -15,67 +15,53 @@ description: "This section describes the subsequent possible actions that can be This section describes the subsequent possible actions that can be performed with the newly added or existing applications. -## Check and Remove Application +## Check Application As soon as the application is successfully provisioned, the following will be created: -* An Application Codebase type will appear in the Codebase list of the Components section. +* An Application Codebase type will appear in the Projects list. * With the **Create** strategy, a new project will be generated on GitHub or another integrated VCS. When **Clone** is chosen, the repository will be forked from the original and copied to the KubeRocketCI-integrated repository. If **Import** is selected, the platform connects to the chosen repository. -The added application will be listed in the Applications list allowing you to do the following: +The added application will be listed in the Projects list allowing you to do the following: -![Applications menu](../assets/user-guide/components/components-manage-components-menu.png "Applications menu") +* Observe it in the Projects list; +* Manage branches; +* Run build/review pipelines; +* View SonarQube/DefectDojo metrics; +* View Merge Requests; +* View Deployments this application is a part of. -* **Open documentation** - Opens the application related documentation page. -* **Create new component** - Opens the **Create new component** menu when clicking. -* **Display settings** - This button allows to show/hide columns to display in the codebase list. By default, all the columns are shown. -* **Actions menu** - Provides additional options for each individual application, such as **Edit** and **Delete**. -* **Edit component** - Allows you to modify the application's settings. You can access this option by clicking the options icon (vertical ellipsis) next to the application's name in the list, and then selecting **Edit**. For more details, see the [Edit Existing Application](#edit-existing-application) section. -* **Delete component** - Deletes the selected application. -* **Component status** - displays the application status. Can be red or green depending on if the KubeRocketCI portal managed to connect to the Git Server with the specified credentials or not. -* **Component name (clickable)** - Displays the application name set during the application creation. - - :::warning - The application that is used in a CD pipeline cannot be removed. - ::: +The Projects lists allows you to see the following information about your applications: +* **Page guide** - Runs the tour that briefly explains the page. +* **Component name (clickable)** - Displays the application name set during the application creation. +* **Actions menu** - Provides additional options for each individual application, such as **Edit** and **Delete**. The application that is used in a Deployment cannot be removed. +* **Status** - Displays the application status. Can be red or green depending on if the KubeRocketCI portal managed to connect to the Git Server with the specified credentials or not. There are also options to sort the applications: - -* **Pagination menu** - select a number of applications displayed per page (15, 25 or 50 rows) and navigate between pages if the number of applications exceeds the capacity of a single page. - * **Filters** - Filter codebases by their name and type. Additionally, sort the existing applications in a table by clicking the sorting icons in the table header. Sort the applications alphabetically by their name, language, build tool, framework, and CI tool. You can also sort the applications by their status: Created, Failed, or In progress. - * **Selector** - Allows you to select multiple applications for bulk delete. - -* **Columns (clickable)** - Sort the existing autotests in a list by clicking the sorting icons in the list header. +* **Columns (clickable)** - Sort the existing applications in a list by clicking the sorting icons in the list header. ## Edit Existing Application -KubeRocketCI Portal provides the ability to enable, disable or edit the Jira Integration functionality for applications. - -1. To edit an application directly from the Applications overview page or when viewing the application data: - - * Select **Edit** in the options icon menu: - - ![Edit application on the Applications overview page](../assets/user-guide/components/application/application-manage-components-codebase-edit-1.png "Edit application on the Applications overview page") - - ![Edit application when viewing the application data](../assets/user-guide/components/application/application-manage-components-codebase-edit-2.png "Edit application when viewing the application data") +There are two options available to edit in the application after its creation: - * The Edit Application dialog opens. +* A pattern to validate a commit message; +* Jira integration. -2. To enable Jira integration, in the **Edit Application** dialog do the following: +You can edit an application directly from the Project overview page or in the Projects list using the **Actions** button. - ![Edit application](../assets/user-guide/components/application/application-manage-edit-codebase-application.png "Edit application") +To enable Jira integration, in the **Edit Project** dialog do the following: - a. Mark the **Integrate with Jira server** check box and fill in the necessary fields. Please see steps d-h of the [Add Application](add-application.md) page. + 1. Mark the **Integrate with Jira server** check box and fill in the necessary fields. Please see steps d-h of the [Add Application](add-application.md) page. - b. Select the **Apply** button to apply the changes. + 2. Select the **Apply** button to apply the changes. -3. To disable Jira integration, in the **Edit Application** dialog do the following: +3. To disable Jira integration, in the **Edit Project** dialog do the following: - a. Clear the **Integrate with Jira server** check box. + 1. Clear the **Integrate with Jira server** check box. - b. Select the **Apply** button to apply the changes. + 2. Select the **Apply** button to apply the changes. 4. To create, edit and delete application branches, please refer to the [Manage Branches](../user-guide/manage-branches.md) page. diff --git a/docs/user-guide/argo-cd-preview.md b/docs/user-guide/argo-cd-preview.md index 684ae685f7..bf55e10daf 100644 --- a/docs/user-guide/argo-cd-preview.md +++ b/docs/user-guide/argo-cd-preview.md @@ -17,9 +17,7 @@ This GitOps-aligned approach significantly enhances deployment control, minimizi ## Set Argo CD Diff Pipeline -To leverage the **deploy-diff-approve** pipeline, select it when creating or editing an Environment: - - ![Create/update environment](../assets/user-guide/argo-cd-preview/create-update-environment.png "Create/update environment") +To leverage the **deploy-diff-approve** pipeline, select it when creating or editing an [Environment](./add-cd-pipeline.md#create-environment). For advanced use cases where you need to incorporate the Argo CD diff functionality into a custom deploy pipeline, please refer to the [Customize Deploy Pipeline](../operator-guide/cd/customize-deploy-pipeline.md) documentation. The [deploy-diff-approve](https://github.com/epam/edp-tekton/blob/master/charts/pipelines-library/templates/pipelines/cd/deploy-diff-approve.yaml) pipeline template provides a reference implementation that can be adapted to your specific requirements. @@ -27,17 +25,13 @@ For advanced use cases where you need to incorporate the Argo CD diff functional To utilize the pipeline with Argo CD preview functionality, follow this sequence: -1. Configure the **deploy-diff-approve** pipeline in your Environment as detailed in the [previous section](#set-argo-cd-diff-pipeline). +1. Configure the **deploy-diff-approve** pipeline in your [Environment](./add-cd-pipeline.md#create-environment) as detailed in the [previous section](#set-argo-cd-diff-pipeline). 2. Initiate the deployment of your application. For comprehensive deployment instructions, consult the [Deploy Application](../quick-start/deploy-application.md#application-deployment) documentation. -3. Navigate to the Environment details page, select the **Pipelines** tab, and access the pipeline by selecting its name: - - ![Click pipeline name](../assets/user-guide/argo-cd-preview/click-pipeline.png "Click pipeline name") - -4. Within the Pipeline details page, locate the **approve-diff** Step within the **preview-changes** Task. The Argo CD application link will be displayed in the logs. Select this link to open the corresponding Argo CD application: +3. Navigate to the Environment details page, select the **Pipelines** tab, and access the pipeline by clicking its name. - ![Argo CD link](../assets/user-guide/argo-cd-preview/argo-cd-link.png "Argo CD link") +4. Within the Pipeline details page, locate the **approve-diff** Step within the **preview-changes** Task. The Argo CD application link will be displayed in the logs. Select this link to open the corresponding Argo CD application. 5. Authenticate with Argo CD if prompted. diff --git a/docs/user-guide/artifact-versioning.md b/docs/user-guide/artifact-versioning.md index 3c5e87b87b..7a8489c8f6 100644 --- a/docs/user-guide/artifact-versioning.md +++ b/docs/user-guide/artifact-versioning.md @@ -15,17 +15,11 @@ This page describes artifact versioning types in KubeRocketCI, outlining their d Artifact versioning in KubeRocketCI is designed to ensure each build and deployment can be uniquely identified, managed, and traced back to its source. -Artifact versioning is defined for every codebase individually when creating a codebase: +Artifact versioning is defined for every codebase individually when creating a codebase. - ![Select codebase versioning](../assets/user-guide/versioning/codebase_versioning.png "Select codebase versioning") +A new application version appears when a build pipeline run completes successfully. A successfully built artifact is marked with the new version once the `git-tag`, `update-cbb`, and `update-cbis` steps complete successfully. -A new application version appears when a build pipeline run completes successfully. A successfully built artifact is marked with the new version once the `git-tag`, `update-cbb`, and `update-cbis` steps complete successfully: - - ![Git-tag step](../assets/user-guide/versioning/codebase_versioning.png "Git-tag step") - -Application version can also be seen in the pipeline that built the version: - - ![Versions in pipelines](../assets/user-guide/versioning/versions_in_pipelines.png "Versions in pipelines") +Application version can also be seen in the pipeline that built the version. ## Versioning Types @@ -35,13 +29,17 @@ KubeRocketCI supports two versioning types: default and semver. They offer diffe Default versioning generates versions based on the branch name and datetime, e.g. (`BRANCH-DATETIME`): - ![Default versioning](../assets/user-guide/versioning/default_versioning.png "Default versioning") +```bash +0.0.1-20260304-145929 +``` ### Semantic Versioning Semantic versioning (semver) structures versions as `MAJOR.MINOR.PATCH-BUILD_ID`, based on the [semantic versioning standards](https://semver.org/): - ![Semantic versioning](../assets/user-guide/versioning/semantic_versioning.png "Semantic versioning") +``` +build/0.1.0-SNAPSHOT.1 +``` Several other resources are also involved in managing semantic versioning. @@ -50,13 +48,9 @@ The first resource is **CodebaseBranch**. It contains data major version and bui - **Version History**: A record of all versions generated from the branch. - **Build Information**: Details of the current and most recent successful builds, which may include version identifiers. -**CodebaseBranch** data is displayed in the codebase details page: - - ![CodebaseBranch data](../assets/user-guide/versioning/codebasebranch_data.png "CodebaseBranch data") - -The second resource is **CodebaseImageStream**. It contains application container versions built for container registry. The available container versions are displayed in the environment details page when deploying an application: +**CodebaseBranch** data is displayed in the codebase details page. - ![CodebaseImageStream data](../assets/user-guide/versioning/codebaseimagestream_data.png "CodebaseImageStream data") +The second resource is **CodebaseImageStream**. It contains application container versions built for container registry. The available container versions are displayed in the environment details page when deploying an application. ## Custom Versioning diff --git a/docs/user-guide/auto-stable-trigger-type.md b/docs/user-guide/auto-stable-trigger-type.md index 6aba6fb8ea..e427b0ee7a 100644 --- a/docs/user-guide/auto-stable-trigger-type.md +++ b/docs/user-guide/auto-stable-trigger-type.md @@ -21,20 +21,22 @@ In KubeRocketCI, application deployment can be triggered once the new applicatio * **Auto-deploy**: Automatically triggers the deployment pipeline as soon as a new application version is built, all the applications will deployed with latest version available. * **Auto-stable**: This one is similar to **Auto-deploy** but features more complicated logic. In this trigger type, the newly released application version is deployed, whereas the rest of applications in the Environment will use the **Stable** image tag, even if they have an application image version marked as **Latest**. If there are no application images with the **Stable** tag available, the **Latest** application version will be used. -The diagram below illustrates how the **Auto-deploy** trigger type works: - - ![Auto-deploy trigger type](../assets/operator-guide/autodeploy-trigger-type-scheme.png "Auto-deploy trigger type") +### Auto-Deploy As soon as a new application artifact is built, it is immediately deployed to the environment along with the rest of the applications using their latest versions. In this strategy, if several application versions were built in a short period of time, only the latest of them will be deployed. -The diagram below illustrates how the **Auto-stable** trigger type works: + ![Auto-deploy trigger type](../assets/operator-guide/autodeploy-trigger-type-scheme.png "Auto-deploy trigger type") - ![Auto-stable trigger type](../assets/operator-guide/auto-stable-trigger-type-scheme.png "Auto-stable trigger type") +### Auto-Stable In contrast to the **Auto-deploy** trigger type, where deploy pipelines always deploy the latest application version, **Auto-stable** can safeguard application stability by preventing deployment of latest application version if this version wasn't unstable. If there are several build pipelines running at a time, they are placed in a queue and deployed consequently. + ![Auto-stable trigger type](../assets/operator-guide/auto-stable-trigger-type-scheme.png "Auto-stable trigger type") + +### Latest vs Stable Versions + Understanding the difference between **Latest** and **Stable** tags is essential: * **Latest**: Assigned to an application image as soon as a new version is built by developers and deployment process was initiated with this new application version. Application can have no tags if a new version is built but build pipeline wasn't completed successfully. @@ -56,25 +58,17 @@ Before proceeding, ensure you already have at least two [applications](../user-g To enable the auto-stable deployment strategy, follow the steps below: -1. When creating/editing Environment, set the **auto-stable** trigger type: - - ![Auto-stable trigger type](../assets/operator-guide/auto-stable-trigger-type.png "Auto-stable trigger type") - -2. Make sure you have an application with both **latest** and **stable** image tags: - - ![Stable and latest application tag](../assets/operator-guide/stable-and-latest.png "Stable and latest application tag") - -3. Build one of your application that are included in the Environment: +1. When creating/editing Environment, set the **auto-stable** trigger type. - ![Application build](../assets/operator-guide/build_application.png "Application build") +2. Make sure you have an application with both **latest** and **stable** image tags. -4. View the deploy pipeline details to see that it deploys only stable application version: +3. Build one of your application that are included in the Environment. - ![Applications image versions](../assets/operator-guide/pipeline-details.png "Applications image versions") +4. View the deploy pipeline details to see that it deploys only stable application version. Note that **notifications-service** application, which has both both **Latest** and **Stable** images, was deployed with the stable version. While the application version 2 (latest) exists, it was deployed with the version 1 (stable). ## Related Articles -* [Manage Deployment Flows](../user-guide/manage-environments.md) +* [Manage Deployments](../user-guide/manage-environments.md) * [Add Application](../user-guide/add-application.md) diff --git a/docs/user-guide/autotest.md b/docs/user-guide/autotest.md index 8d9fc4aea8..97c4722f0b 100644 --- a/docs/user-guide/autotest.md +++ b/docs/user-guide/autotest.md @@ -1,9 +1,7 @@ --- - title: "Manage Autotests" sidebar_label: "Manage Autotests" description: "Guide to managing autotests in KubeRocketCI, including editing, integrating with Jira, and adding as quality gates in CI/CD workflows." - --- @@ -15,112 +13,89 @@ description: "Guide to managing autotests in KubeRocketCI, including editing, in This section describes the subsequent possible actions that can be performed with the newly added or existing autotests. -## Check and Remove Autotest +## Check Autotest As soon as the autotest is successfully provisioned, the following will be created: -* An Autotest Codebase type will appear in the Codebase list of the Components section. -* With the **Create** strategy, a new project will be generated on GitHub or another integrated VCS. When **Clone** is chosen, the repository will be forked from the original and copied to the KubeRocketCI-integrated repository. If **Import** is selected, the platform connects to the chosen repository. +* An Autotest Codebase type will appear in the Projects list. +* With the **Clone** or **Import** strategy, the repository will be copied or connected to the KubeRocketCI-integrated Version Control System. Autotests do not support the **Create** strategy. + +The added autotest will be listed in the Projects list allowing you to do the following: + +* Observe it in the Projects list; +* Manage branches; +* Run build/review pipelines; +* View SonarQube/DefectDojo metrics; +* View Merge Requests. :::info - To navigate quickly to Tekton, Version Control System, SonarQube, Nexus, and other resources, click the **Overview** section on the navigation bar and hit the necessary link. + Autotests cannot be deployed via Deployments; only applications can. You can use autotests as quality gates in Deployments—see [Add Autotest as a Quality Gate](#add-autotest-as-a-quality-gate). ::: -The added autotest will be listed in the Autotests list allowing you to do the following: - -![Autotests page](../assets/user-guide/components/components-manage-components-menu.png "Autotests page") +The Projects list allows you to see the following information about your autotests: -* **Open documentation** - Opens the autotest related documentation page. -* **Create new component** - Opens the **Create new component** menu when clicking. -* **Display settings** - This button allows to show/hide columns to display in the codebase list. By default, all the columns are shown. -* **Actions menu** - Provides additional options for each individual autotest, such as **Edit** and **Delete**. -* **Edit component** - Allows you to modify the autotest's settings. You can access this option by clicking the options icon (vertical ellipsis) next to the autotest's name in the list, and then selecting **Edit**. For more details, see the [Edit Existing Autotest](#edit-existing-autotest) section. -* **Delete component** - Deletes the selected autotest. -* **Component status** - displays the autotest status. Can be red or green depending on if the KubeRocketCI portal managed to connect to the Git Server with the specified credentials or not. +* **Page guide** - Runs the tour that briefly explains the page. * **Component name (clickable)** - Displays the autotest name set during the autotest creation. - - :::warning - The application that is used in a CD pipeline cannot be removed. - ::: +* **Actions menu** - Provides additional options for each individual autotest, such as **Edit** and **Delete**. An autotest that is used as a quality gate in a Deployment cannot be removed. +* **Status** - Displays the autotest status. Can be red or green depending on if the KubeRocketCI portal managed to connect to the Git Server with the specified credentials or not. There are also options to sort the autotests: -* **Pagination menu** - select a number of autotests displayed per page (15, 25 or 50 rows) and navigate between pages if the number of autotests exceeds the capacity of a single page. - * **Filters** - Filter codebases by their name and type. Additionally, sort the existing autotests in a table by clicking the sorting icons in the table header. Sort the autotests alphabetically by their name, language, build tool, framework, and CI tool. You can also sort the autotests by their status: Created, Failed, or In progress. - * **Selector** - Allows you to select multiple autotests for bulk delete. - * **Columns (clickable)** - Sort the existing autotests in a list by clicking the sorting icons in the list header. ## Edit Existing Autotest -KubeRocketCI portal provides the ability to enable, disable or edit the Jira Integration functionality for autotests. - -1. To edit an autotest directly from the Autotests overview page or when viewing the autotest data: +There are two options available to edit in the autotest after its creation: - Select **Edit** in the options icon menu: +* A pattern to validate a commit message; +* Jira integration. - ![Edit autotest on the autotests overview page](../assets/user-guide/components/autotests/autotests-manage-components-codebase-edit-1.png "Edit autotest on the autotests overview page") +You can edit an autotest directly from the Project overview page or in the Projects list using the **Actions** button. - ![Edit autotest when viewing the autotest data](../assets/user-guide/components/autotests/autotests-manage-components-codebase-edit-2.png "Edit autotest when viewing the autotest data") +To enable Jira integration, in the **Edit Project** dialog do the following: -2. To enable Jira integration, on the **Edit Autotest** page do the following: + 1. Mark the **Integrate with Jira server** check box and fill in the necessary fields. Please see steps d-h of the [Add Autotest](add-autotest.md) page. - ![Edit autotest](../assets/user-guide/components/autotests/autotests-manage-edit-codebase-autotests.png "Edit library") + 2. Select the **Apply** button to apply the changes. - a. Mark the **Integrate with Jira server** check box and fill in the necessary fields. Please see steps d-h on the [Add Autotests](add-autotest.md) page. +To disable Jira integration, in the **Edit Project** dialog do the following: - b. Click the **Apply** button to apply the changes. + 1. Clear the **Integrate with Jira server** check box. - :::note - To adjust the Jira integration functionality, first apply the necessary changes described on the [Adjust Jira Integration](../operator-guide/project-management-and-reporting/jira-integration.md). - ::: + 2. Select the **Apply** button to apply the changes. -3. To disable Jira integration, in the **Edit Autotest** dialog do the following: - - * Clear the **Integrate with Jira server** check box. - - * Click the **Apply** button to apply the changes. - -4. To create, edit and delete autotest branches, please refer to the [Manage Branches](../user-guide/manage-branches.md) page. +To create, edit and delete autotest branches, please refer to the [Manage Branches](manage-branches.md) page. ## Add Autotest as a Quality Gate -In order to add an autotest as a quality gate to a newly added CD pipeline, do the following: - -1. Create a CD pipeline with the necessary parameters. Please refer to the [Add CD Pipeline](add-cd-pipeline.md) section for the details. - -2. In the **Stages** menu, select the **Autotest** quality gate type. It means the promoting process should be confirmed by the successful passing of the autotests. +In order to add an autotest as a quality gate to a Deployment, do the following: +1. Create a Deployment with the necessary parameters. Please refer to the [Add CD Pipeline](add-cd-pipeline.md) section for the details. +2. In the **Stages** menu, select the **Autotest** quality gate type. The promoting process will then require the autotest to pass successfully. 3. In the additional fields, select the previously created autotest name and specify its branch. - -4. After filling in all the necessary fields, click the Create button to start the provisioning of the pipeline. After the CD pipeline is added, the new namespace containing the stage name will be created in Kubernetes (in OpenShift, a new project will be created) with the following name pattern: _[cluster name]-[cd pipeline name]-[stage name]_. +4. After filling in all the necessary fields, click **Create** to start the provisioning of the pipeline. ## Configure Autotest Launch at Specific Stage -In order to configure the added autotest launch at the specific stage with necessary parameters, do the following: - -1. Add the necessary stage to the CD pipeline. Please refer to the [Add CD Pipeline](add-cd-pipeline.md) documentation for the details. +To configure the autotest to run at a specific stage with the necessary parameters: +1. Add the necessary stage to the Deployment. Please refer to the [Add CD Pipeline](add-cd-pipeline.md) documentation for the details. 2. Navigate to the **run.json** file and add the stage name and the specific parameters. ## Launch Autotest Locally -There is an ability to run the autotests locally using the IDEA (Integrated Development Environment Application, such as IntelliJ, NetBeans etc.). To launch the autotest project for the local verification, perform the following steps: - -1. Clone the project to the local machine. - -2. Open the project in IDEA and find the **run.json** file to copy out the necessary command value. +You can run autotests locally using an IDE (such as IntelliJ or NetBeans). To run the autotest project for local verification: +1. Clone the project to your local machine. +2. Open the project in the IDE and find the **run.json** file to copy the necessary command value. 3. Paste the copied command value into the Command line field and run it with the necessary values and namespace. - -4. As a result, all the launched tests will be executed. +4. All the launched tests will be executed. ## Related Articles -* [Add Application](add-application.md) -* [Add Autotests](add-autotest.md) +* [Add Autotest](add-autotest.md) +* [Manage Branches](manage-branches.md) * [Add CD Pipeline](add-cd-pipeline.md) * [Adjust Jira Integration](../operator-guide/project-management-and-reporting/jira-integration.md) -* [Manage Branches](../user-guide/manage-branches.md) diff --git a/docs/user-guide/cd-pipeline-details.md b/docs/user-guide/cd-pipeline-details.md index d492d48150..bc3eba4863 100644 --- a/docs/user-guide/cd-pipeline-details.md +++ b/docs/user-guide/cd-pipeline-details.md @@ -24,7 +24,6 @@ Every codebase has a branch that has its own codebase stream - a Docker containe For more information on the main terms used in KubeRocketCI, please refer to the [KubeRocketCI Glossary](../glossary.md) ::: -![KubeRocketCI CD pipeline](../assets/user-guide/edp-cd-pipeline.png "KubeRocketCI CD pipeline") Explore the details of the CD pipeline below. diff --git a/docs/user-guide/cd-pipeline-variables-injection.md b/docs/user-guide/cd-pipeline-variables-injection.md index daf07035c4..bc78096496 100644 --- a/docs/user-guide/cd-pipeline-variables-injection.md +++ b/docs/user-guide/cd-pipeline-variables-injection.md @@ -37,24 +37,16 @@ Additionally, customize your deploy pipeline to utilize parameters efficiently. To add a key-value variable in deploy pipelines, follow the steps below: -1. Navigate to the **KubeRocketCI portal** -> **Deployment Flows**: +1. Navigate to the **KubeRocketCI portal** -> **Deployments**. - ![Deployment Flows section](../assets/user-guide/deployment-flows-page.png "Deployment Flows section") +2. Enter your Deployment and then enter the Environment you need to add a variable to. In the environment details page, select the **Variables** tab. Click the **+** button to add a variable. If there are no variables yet, click the **Click here to add a new variable** message. -2. Enter your deployment flow and then enter the environment you need to add a variable to. In the environment details page, select the **Variables** tab. Click the **+** button to add a variable: +3. Specify the variables and click **Save**. - ![Variables tab](../assets/user-guide/variables-tab.png "Variables tab") - -3. Specify the variables and click **Save**: - - ![Variables populated](../assets/user-guide/add-variables.png "Variables populated") - -4. Verify that the deploy pipeline uses your variables: - - ![Variables demonstration](../assets/user-guide/variables.gif "Variables demonstration") +4. Verify that the deploy pipeline uses your variables. ## Related Articles * [Customize Deploy Pipeline](../operator-guide/cd/customize-deploy-pipeline.md) * [Add Deployment Flow](../user-guide/add-cd-pipeline.md) -* [Manage Deployment Flows](../user-guide/manage-environments.md) +* [Manage Deployments](../user-guide/manage-environments.md) diff --git a/docs/user-guide/change-container-registry.md b/docs/user-guide/change-container-registry.md index df03501b8f..840ec08192 100644 --- a/docs/user-guide/change-container-registry.md +++ b/docs/user-guide/change-container-registry.md @@ -25,9 +25,8 @@ To reset container registry integration from the KubeRocketCI, follow the steps 1. In the KubeRocketCI main menu, navigate to **Configuration** -> **Artifacts storage** -> **Registry**. - 2. Click the **Reset registry** button, type the `confirm` word and then click **Confirm**: + 2. Click the **Reset registry** button, type the `confirm` word and then click **Confirm**. - ![Registry settings](../assets/operator-guide/container-registry-reset.png "Registry settings") ## Update Registry for the Existing Components and Environments diff --git a/docs/user-guide/ci-pipeline-details.md b/docs/user-guide/ci-pipeline-details.md index 223dd2adab..bc82ddc320 100644 --- a/docs/user-guide/ci-pipeline-details.md +++ b/docs/user-guide/ci-pipeline-details.md @@ -16,7 +16,6 @@ There are three codebase types in KubeRocketCI: For more information on the above mentioned codebase types, please refer to the [Add Application](add-application.md), [Add Library](add-library.md), [Add Autotests](add-autotest.md) and [Autotest as Quality Gate](../use-cases/autotest-as-quality-gate.md) pages. ::: -![KubeRocketCI CI pipeline](../assets/user-guide/edp-ci-pipeline.png "KubeRocketCI CI pipeline") ## Related Articles diff --git a/docs/user-guide/cluster.md b/docs/user-guide/cluster.md index 264aca8a7b..044d90c3f4 100644 --- a/docs/user-guide/cluster.md +++ b/docs/user-guide/cluster.md @@ -19,25 +19,23 @@ In a nutshell, cluster in KubeRocketCI Portal is a Kubernetes secret that stores The added cluster will be listed in the clusters list allowing you to do the following: -![Clusters list](../assets/user-guide/krci-portal-cluster-overview.png "Clusters list") - -* **Open documentation** - opens the cluster related documentation page. -* **Add a new cluster** - displays the cluster creation form. +* **Learn more** - opens the cluster related documentation page. +* **+ Add cluster** - displays the cluster creation form. * **Cluster properties** - shows the specified cluster properties. * **Delete cluster** - remove cluster by clicking the recycle bin icon. * **Undo/Save changes** - these buttons apply or revert changes made to the cluster configuration. ## View Authentication Data -To view authentication data that is used to log in to the cluster, run the `kubectl describe` command: +To view authentication data that is used to connect to the cluster, click the **eye** icon in the corresponding field or use the `kubectl describe` command: ```bash - kubectl describe secret cluster_name -n krci + kubectl get secret cluster_name -n krci -o yaml ``` ## Delete Cluster -To delete cluster, use the `kubectl delete` command as follows: +To delete cluster, click the bin icon, enter cluster name, and confirm deletion. Alternatively, use the `kubectl delete` command as follows: ```bash kubectl delete secret cluster_name -n krci diff --git a/docs/user-guide/configuration-overview.md b/docs/user-guide/configuration-overview.md index cd4f1507e2..42bc3cfdd6 100644 --- a/docs/user-guide/configuration-overview.md +++ b/docs/user-guide/configuration-overview.md @@ -22,14 +22,12 @@ Here is the list of all the sections provided in the Configuration tab. Familiar | Configuration Section | Description | |:-|:-| | [Quick Access](quick-links.md) | Configure quick links for quick access to required tools that will be displayed on the Overview page or in specific resource details, such as application or stage details. Additionally, this section is used to configure widgets, such as SonarQube and DependencyTrack. | -| [Tekton](../user-guide/tekton-pipelines.md) | View all the Tekton Pipelines and Tasks CRDs created in the platform. This section allows to oversee all the Tekton resources and compare them to one another. | -| [Artifacts Storage](../user-guide/manage-container-registries.md) | This section contains settings on related to application deployment. There are three tabs in the section:
  • Nexus: Integrate platform with Nexus as an application artifact storage solution.
  • Registry: Integrate with a container registry to store container artifacts. The supported container registry solutions are AWS ECR, DockerHub, Harbor, Nexus, GitHub CR, and OpenShift CR.
| -| [Deployment](../quick-start/integrate-container-registry.md) | This section contains settings on integrating both artifact and container registries. There are two tabs in the section:
  • Clusters: Connect the platform to a remote cluster to deploy application into them.
  • GitOps: Create a GitOps repository to redefine parameters for application Helm charts.
  • Argo CD: Configure Argo CD integration as a mandatory component for deploying applications.
| +| [Artifacts Storage](../user-guide/manage-container-registries.md) | This section contains settings on related to application deployment. There are two tabs in the section:
  • Nexus: Integrate platform with Nexus as an application artifact storage solution.
  • Registry: Integrate with a container registry to store container artifacts. The supported container registry solutions are AWS ECR, DockerHub, Harbor, Nexus, GitHub CR, and OpenShift CR.
| +| [Deployment](../quick-start/integrate-container-registry.md) | This section contains settings on integrating both artifact and container registries. There are three tabs in the section:
  • Clusters: Connect the platform to a remote cluster to deploy application into them.
  • GitOps: Create a GitOps repository to redefine parameters for application Helm charts.
  • Argo CD: Configure Argo CD integration as a mandatory component for deploying applications.
| | [Security](../operator-guide/devsecops/overview.md) | Integrate platform with [DefectDojo](../operator-guide/devsecops/defectdojo.md) and [DependencyTrack](../operator-guide/devsecops/dependency-track.md) to scan your codebases for security vulnerabilities.| -| [Code Quality](../operator-guide/code-quality/sonarqube.md) | Integrate platform with SonarQube as a mandatory component to scan your application when executing deploy pipelines. This integration also enables users to view code quality metrics and dependency scan results of your application directly in the KubeRocketCI portal. | +| [Code Quality](../operator-guide/code-quality/sonarqube.md) | Integrate platform with SonarQube as a mandatory component to scan your application when executing build and review pipelines. This integration also enables users to view code quality metrics and dependency scan results of your application directly in the KubeRocketCI portal. | | [Version Control System](../user-guide/add-git-server.md) | Connect platform to a Git Server as a mandatory component to enable a CI/CD workflow. | | [Management Tool](../operator-guide/project-management-and-reporting/jira-integration.md) | Integrate platform with a Jira server to add pull the the useful codebase metadata into Jira tickets. | -| [Gen AI](../user-guide/add-ai-assistant.md) | Integrate platform an AI assistant for getting intellectual answers to any questions in the chat. | ## Related Articles diff --git a/docs/user-guide/git-server-overview.md b/docs/user-guide/git-server-overview.md index f9e8e47e5d..7d9e1aa70c 100644 --- a/docs/user-guide/git-server-overview.md +++ b/docs/user-guide/git-server-overview.md @@ -26,21 +26,20 @@ The Git Server is set via the **global.gitProviders** parameter of the [values.y To view the current Git Server, you can open Portal **Configuration** -> **Git Servers** and inspect the following properties: -![Git Server menu](../assets/user-guide/krci-portal-git-server-overview.png "Git Server menu") * **Git Server status and name** - displays the Git Server status, which depends on the Git Server integration status (Success/Failed). * **Git Server properties** - displays the Git Server type, its host address, username, SSH/HTTPS port, public and private SSH keys. -* **Open documentation** - opens the "Manage Git Servers" documentation page. +* **Learn more** - opens the "Manage Git Servers" documentation page. * **Undo/Save changes** - these buttons apply or revert changes made to the Git Server. -* **Add a new Git Server** - add a new blank to specify the new Git Server's parameters. +* **+ Add Git Server** - add a new blank to specify the new Git Server's parameters. * **Delete a Git Server** - deletes the Git Server after confirmation. ## View Authentication Data -To view authentication data that is used to connect to the Git server, use `kubectl describe` command as follows: +To view authentication data that is used to connect to the Git server, click the **eye** icon in the corresponding field or use the `kubectl describe` command as follows: ```bash - kubectl describe GitServer git_server_name -n krci + kubectl get secret ci- -n krci -o yaml ``` ## Delete Git Server @@ -60,14 +59,10 @@ There are two ways for deleting Git server: using KubeRocketCI portal or CLI. 1. Navigate to **KubeRocketCI portal** -> **Configuration** -> **Version Control System**. - 2. In the **Version Control System** tab, click the bin icon: - - ![Delete Git server](../assets/user-guide/krci-portal-delete-git-server.png "Delete Git server") + 2. In the **Version Control System** tab, click the bin icon. 3. In the confirmation window, enter **confirm** and click **Delete**. - ![Confirm deletion](../assets/user-guide/git-server-confirm-deletion.png "Confirm deletion") - diff --git a/docs/user-guide/gitops.md b/docs/user-guide/gitops.md index 54fb4e7dd8..6ceda2673e 100644 --- a/docs/user-guide/gitops.md +++ b/docs/user-guide/gitops.md @@ -30,9 +30,7 @@ The purpose of the `GitOps` section is to provide users with the ability to cust GitOps repository is added in two steps: -1. Navigate to **Configuration** -> **Deployment**-> **GitOps** and click the **+ Add GitOps Repository** button: - - ![Required fields](../assets/user-guide/gitops-section.png "GitOps section") +1. Navigate to **Configuration** -> **Deployment**-> **GitOps** and click the **+ Add GitOps repository** button. 2. Select the creation strategy, fill in the required fields, and click **Save**: @@ -47,7 +45,6 @@ GitOps repository is added in two steps: The **Create** strategy allows you to create a new repository from scratch: - ![Create GitOps repository](../assets/user-guide/gitops-menu.png "Create GitOps repository") * **Git server**: Select the [added Git server](./add-git-server.md) where the GitOps repository will be created. * **Git repo relative path**: Enter your Git account. @@ -59,7 +56,6 @@ GitOps repository is added in two steps: Select the **Import** strategy if you already have a repository that stores your application Helm charts' configurations: - ![Import GitOps repository](../assets/user-guide/gitops-menu-import.png "Import GitOps repository") * **Git server**: Select the [added Git server](./add-git-server.md) that has credentials to access the GitOps repository. * **Git repo relative path**: Enter your Git account. @@ -71,12 +67,8 @@ GitOps repository is added in two steps: 3. Check the GitOps repository connected to the platform: - ![System Codebase](../assets/user-guide/gitops-repo-added.png "System Codebase") - As the result, the `Codebase` of `system` type will be added to the Codebase list of the **Components** section: - ![GitOps Codebase](../assets/user-guide/system-codebase.png "GitOps Codebase") - :::warning The platform allows only one GitOps repository at a time. ::: @@ -91,7 +83,6 @@ Once the GitOps repository is added to the platform, you can set custom paramete 3. Navigate to the **Environments** section. Open the created environment, open its stage and deploy it with the **Values override** checkbox selected as it is shown below: - ![GitOps Codebase](../assets/user-guide/values-override-deploy.png "GitOps Codebase") :::note Ensure to add the [credentials template](https://argo-cd.readthedocs.io/en/latest/user-guide/private-repositories/#credential-templates) in the Argo CD settings to grant Argo CD access to both your GitOps and codebase repositories. @@ -124,7 +115,6 @@ In this example, the `line-length` and `document-start` rules are disabled. For After creating the `.yamllint` file, commit it to the main branch of the GitOps repository. Once the changes are applied, the `yamllint` scan in review and build pipelines will use the custom rules defined in the `.yamllint` file. - ![Yamllint rules](../assets/user-guide/yamllint-rules.png "Yamllint rules") ## Delete GitOps Repository @@ -135,7 +125,7 @@ In case you need to delete the GitOps repository, do the following: 2. Delete the Codebase custom resource using the `kubectl delete` command: ```bash - kubectl delete Codebase krci-gitops -n krci + kubectl delete Codebase -n krci ``` ## Related Articles diff --git a/docs/user-guide/index.md b/docs/user-guide/index.md index d49ac071b2..14888b4a79 100644 --- a/docs/user-guide/index.md +++ b/docs/user-guide/index.md @@ -1,11 +1,12 @@ --- title: "User Guide: Portal Features and CI/CD Flow" description: "The KubeRocketCI portal user guide is intended for developers and provides details on working with the KubeRocketCI portal, different codebase types, and the KubeRocketCI CI/CD flow." -sidebar_label: "Overview" +sidebar_label: "Main Menu" --- import Head from '@docusaurus/Head'; +import { UserGuideCards } from '@site/src/features/user-guide/components/UserGuideCards'; @@ -25,26 +26,10 @@ The KubeRocketCI portal user guide is intended for developers and provides detai The KubeRocketCI portal is a central management tool in the KubeRocketCI ecosystem that provides the ability to define pipelines, project resources and new technologies in a simple way. Using the KubeRocketCI portal enables to manage business entities: * Create such codebase types as Applications, Libraries, Autotests and Infrastructures; -* Create/Update CD Pipelines; -* Add external Git servers and Clusters. +* Manage CI/CD Pipelines; +* Add Git Servers and external Clusters; +* Integrate tools, such as SonarQube, Jira, DefectDojo, etc. -Below is the Overview page of the KubeRocketCI portal: +Choose a platform section below to open its overview and related documentation: -![Overview page](../assets/user-guide/kuberocketci-portal-overview-page.png "Overview page") - -* **Application widgets** – shows the information on codebases created in the default and allowed namespaces, reflecting the overall amount of entities and their statuses. -* **Top bar panel** – contains chat assistant button (if configured) documentation link, notifications, KubeRocketCI portal settings, cluster settings, such as default and allowed namespaces. -* **Quick links** – displays the corresponding links to the major adjusted tool set. -* **KubeRocketCI/Kubernetes mode switcher** - Toggle between KubeRocketCI and K8s modes to view and configure corresponding resources. -* **Create resource as code** – Allows creating resources using Kubernetes manifests. - -KubeRocketCI portal is a complete tool allowing to manage and control the codebases (applications, autotests, libraries and infrastructures) added to the environment as well as to create a CD pipeline. - -Inspect the main features available in the KubeRocketCI portal by following the corresponding link: - -* [Add Application](add-application.md) -* [Add Autotest](add-autotest.md) -* [Add Library](add-library.md) -* [Add Git Server](add-git-server.md) -* [Add CD Pipeline](add-cd-pipeline.md) -* [Add Quality Gate](add-quality-gate.md) + diff --git a/docs/user-guide/infrastructure.md b/docs/user-guide/infrastructure.md index 32bd18d8a1..8dc3cf21b5 100644 --- a/docs/user-guide/infrastructure.md +++ b/docs/user-guide/infrastructure.md @@ -1,9 +1,7 @@ --- - title: "Manage Infrastructures" sidebar_label: "Manage Infrastructures" description: "Guide to managing infrastructures in KubeRocketCI, including setup, modification, and integration with Jira for comprehensive development management." - --- @@ -15,71 +13,63 @@ description: "Guide to managing infrastructures in KubeRocketCI, including setup This section describes the subsequent possible actions that can be performed with the newly added or existing infrastructures. -## Check and Remove Infrastructure +## Check Infrastructure As soon as the infrastructure is successfully provisioned, the following will be created: -* An Infrastructure Codebase type will appear in the Codebase list of the Components section. +* An Infrastructure Codebase type will appear in the Projects list. * With the **Create** strategy, a new project will be generated on GitHub or another integrated VCS. When **Clone** is chosen, the repository will be forked from the original and copied to the KubeRocketCI-integrated repository. If **Import** is selected, the platform connects to the chosen repository. -The added infrastructure will be listed in the infrastructure list allowing you to do the following: +The added infrastructure will be listed in the Projects list allowing you to do the following: -![Components menu](../assets/user-guide/components/components-manage-components-menu.png "Components menu") +* Observe it in the Projects list; +* Manage branches; +* Run build/review pipelines; +* View SonarQube/DefectDojo metrics; +* View Merge Requests. -* **Open documentation** - Opens the infrastructure related documentation page. -* **Create new component** - Opens the **Create new component** menu when clicking. -* **Display settings** - This button allows to show/hide columns to display in the codebase list. By default, all the columns are shown. -* **Actions menu** - Provides additional options for each individual infrastructure, such as **Edit** and **Delete**. -* **Edit component** - Allows you to modify the infrastructure's settings. You can access this option by clicking the options icon (vertical ellipsis) next to the infrastructure's name in the list, and then selecting **Edit**. For more details, see the [Edit Existing Infrastructure](#edit-existing-infrastructure) section. -* **Delete component** - Deletes the selected infrastructure. -* **Component status** - displays the infrastructure status. Can be red or green depending on if the KubeRocketCI portal managed to connect to the Git Server with the specified credentials or not. -* **Component name (clickable)** - Displays the infrastructure name set during the infrastructure creation. +:::info + Infrastructures cannot be deployed via Deployments; only applications can. Infrastructure codebases are used to define and manage cloud or platform resources (e.g. via Terraform). +::: - :::warning - The application that is used in a CD pipeline cannot be removed. - ::: +The Projects list allows you to see the following information about your infrastructures: -There are also options to sort the infrastructures: +* **Page guide** - Runs the tour that briefly explains the page. +* **Component name (clickable)** - Displays the infrastructure name set during the infrastructure creation. +* **Actions menu** - Provides additional options for each individual infrastructure, such as **Edit** and **Delete**. +* **Status** - Displays the infrastructure status. Can be red or green depending on if the KubeRocketCI portal managed to connect to the Git Server with the specified credentials or not. -* **Pagination menu** - select a number of infrastructures displayed per page (15, 25 or 50 rows) and navigate between pages if the number of infrastructures exceeds the capacity of a single page. +There are also options to sort the infrastructures: * **Filters** - Filter codebases by their name and type. Additionally, sort the existing infrastructures in a table by clicking the sorting icons in the table header. Sort the infrastructures alphabetically by their name, language, build tool, framework, and CI tool. You can also sort the infrastructures by their status: Created, Failed, or In progress. - * **Selector** - Allows you to select multiple infrastructures for bulk delete. - -* **Columns (clickable)** - Sort the existing infrastructures in a list by clicking the sorting icons in the list header. +* **Columns (clickable)** - Select columns to display and sort the existing infrastructures in a list by clicking the sorting icons in the list header. ## Edit Existing Infrastructure -KubeRocketCI portal provides the ability to enable, disable or edit the Jira Integration functionality for infrastructures. - -1. To edit an infrastructure directly from the infrastructures overview page or when viewing the infrastructure data: - - * Select **Edit** in the options icon menu: - - ![Edit infrastructure on the Infrastructures overview page](../assets/user-guide/components/infrastructure/infrastructure-manage-components-edit-infrastructure-1.png "Edit infrastructure on the Infrastructures overview page") - - ![Edit infrastructure when viewing the infrastructure data](../assets/user-guide/components/infrastructure/infrastructure-manage-components-edit-infrastructure-2.png "Edit infrastructure when viewing the infrastructure data") +There are two options available to edit in the infrastructure after its creation: - * The **Edit Infrastructure** dialog opens. +* A pattern to validate a commit message; +* Jira integration. -2. To enable Jira integration, in the **Edit Infrastructure** dialog do the following: +You can edit an infrastructure directly from the Project overview page or in the Projects list using the **Actions** button. - ![Edit infrastructure](../assets/user-guide/components/infrastructure/infrastructure-manage-edit-codebase-infrastructure.png "Edit infrastructure") +To enable Jira integration, in the **Edit Project** dialog do the following: - a. Mark the **Integrate with Jira server** check box and fill in the necessary fields. Please see steps d-h on the [Add Infrastructure page](add-infrastructure.md). + 1. Mark the **Integrate with Jira server** check box and fill in the necessary fields. Please see steps d-h of the [Add Infrastructure](add-infrastructure.md) page. - b. Select the **Apply** button to apply the changes. + 2. Select the **Apply** button to apply the changes. -3. To disable Jira integration, in the **Edit Infrastructure** dialog do the following: +To disable Jira integration, in the **Edit Project** dialog do the following: - a. Clear the **Integrate with Jira server** check box. + 1. Clear the **Integrate with Jira server** check box. - b. Select the **Apply** button to apply the changes. + 2. Select the **Apply** button to apply the changes. -4. To create, edit and delete infrastructure branches, please refer to the [Manage Branches](../user-guide/manage-branches.md) page. +To create, edit and delete infrastructure branches, please refer to the [Manage Branches](manage-branches.md) page. ## Related Articles * [Add Infrastructure](add-infrastructure.md) -* [Manage Branches](../user-guide/manage-branches.md) +* [Manage Branches](manage-branches.md) +* [Adjust Jira Integration](../operator-guide/project-management-and-reporting/jira-integration.md) diff --git a/docs/user-guide/library.md b/docs/user-guide/library.md index 98d7975e20..ae70434dcb 100644 --- a/docs/user-guide/library.md +++ b/docs/user-guide/library.md @@ -1,9 +1,7 @@ --- - title: "Manage Libraries" sidebar_label: "Manage Libraries" description: "Explore how to manage libraries in KubeRocketCI, including editing details, integrating with Jira, and managing branches for development efficiency." - --- @@ -15,77 +13,63 @@ description: "Explore how to manage libraries in KubeRocketCI, including editing This section describes the subsequent possible actions that can be performed with the newly added or existing libraries. -## Check and Remove Library +## Check Library As soon as the library is successfully provisioned, the following will be created: -* A Library Codebase type will appear in the Codebase list of the Components section. +* A Library Codebase type will appear in the Projects list. * With the **Create** strategy, a new project will be generated on GitHub or another integrated VCS. When **Clone** is chosen, the repository will be forked from the original and copied to the KubeRocketCI-integrated repository. If **Import** is selected, the platform connects to the chosen repository. +The added library will be listed in the Projects list allowing you to do the following: + +* Observe it in the Projects list; +* Manage branches; +* Run build/review pipelines; +* View SonarQube/DefectDojo metrics; +* View Merge Requests. + :::info - To navigate quickly to OpenShift, Tekton, Gerrit, SonarQube, Nexus, and other resources, click the **Overview** section on the navigation bar and hit the necessary link. + Libraries cannot be deployed via Deployments; only applications can. Libraries are used as shared code or pipelines consumed by applications and other project types. ::: -The added library will be listed in the Libraries list allowing to do the following: +The Projects list allows you to see the following information about your libraries: -![Library menu](../assets/user-guide/components/components-manage-components-menu.png "Library menu") - -* **Open documentation** - Opens the library related documentation page. -* **Create new component** - Opens the **Create new component** menu when clicking. -* **Display settings** - This button allows to show/hide columns to display in the codebase list. By default, all the columns are shown. -* **Actions menu** - Provides additional options for each individual library, such as **Edit** and **Delete**. -* **Edit component** - Allows you to modify the library's settings. You can access this option by clicking the options icon (vertical ellipsis) next to the library's name in the list, and then selecting **Edit**. For more details, see the [Edit Existing Library](#edit-existing-library) section. -* **Delete component** - Deletes the selected library. -* **Component status** - displays the library status. Can be red or green depending on if the KubeRocketCI portal managed to connect to the Git Server with the specified credentials or not. +* **Page guide** - Runs the tour that briefly explains the page. * **Component name (clickable)** - Displays the library name set during the library creation. - - :::warning - The application that is used in a CD pipeline cannot be removed. - ::: +* **Actions menu** - Provides additional options for each individual library, such as **Edit** and **Delete**. +* **Status** - Displays the library status. Can be red or green depending on if the KubeRocketCI portal managed to connect to the Git Server with the specified credentials or not. There are also options to sort the libraries: -* **Pagination menu** - select a number of libraries displayed per page (15, 25 or 50 rows) and navigate between pages if the number of libraries exceeds the capacity of a single page. - * **Filters** - Filter codebases by their name and type. Additionally, sort the existing libraries in a table by clicking the sorting icons in the table header. Sort the libraries alphabetically by their name, language, build tool, framework, and CI tool. You can also sort the libraries by their status: Created, Failed, or In progress. - * **Selector** - Allows you to select multiple libraries for bulk delete. - * **Columns (clickable)** - Sort the existing libraries in a list by clicking the sorting icons in the list header. ## Edit Existing Library -KubeRocketCI portal provides the ability to enable, disable or edit the Jira Integration functionality for libraries. - -1. To edit a library directly from the Libraries overview page or when viewing the library data: - - * Select **Edit** in the options icon menu: - - ![Edit library on the libraries overview page](../assets/user-guide/components/library/library-manage-components-library-edit-1.png "Edit library on the libraries overview page") - - * Select **Edit** in the library details menu: - - ![Edit library when viewing the library data](../assets/user-guide/components/library/library-manage-components-library-edit-2.png "Edit library when viewing the library data") +There are two options available to edit in the library after its creation: -2. To enable Jira integration, in the **Edit Library** dialog do the following: +* A pattern to validate a commit message; +* Jira integration. - ![Edit library](../assets/user-guide/components/library/library-manage-edit-codebase-library.png "Edit library") +You can edit a library directly from the Project overview page or in the Projects list using the **Actions** button. - a. Mark the **Integrate with Jira server** check box and fill in the necessary fields. Please see the steps of the [Add Library](add-library.md) page. +To enable Jira integration, in the **Edit Project** dialog do the following: - b. Select the **Apply** button to apply the changes. + 1. Mark the **Integrate with Jira server** check box and fill in the necessary fields. Please see steps d-h of the [Add Library](add-library.md) page. -3. To disable Jira integration, in the **Edit Library** dialog do the following: + 2. Select the **Apply** button to apply the changes. - a. Clear the **Integrate with Jira server** check box. +To disable Jira integration, in the **Edit Project** dialog do the following: - b. Select the **Apply** button to apply the changes. + 1. Clear the **Integrate with Jira server** check box. - As a result, the necessary changes will be applied. + 2. Select the **Apply** button to apply the changes. -4. To create, edit and delete library branches, please refer to the [Manage Branches](../user-guide/manage-branches.md) page. +To create, edit and delete library branches, please refer to the [Manage Branches](manage-branches.md) page. ## Related Articles * [Add Library](add-library.md) -* [Manage Branches](../user-guide/manage-branches.md) +* [Manage Branches](manage-branches.md) +* [Adjust Jira Integration](../operator-guide/project-management-and-reporting/jira-integration.md) diff --git a/docs/user-guide/manage-branches.md b/docs/user-guide/manage-branches.md index 83cadf8d18..6185e31d0b 100644 --- a/docs/user-guide/manage-branches.md +++ b/docs/user-guide/manage-branches.md @@ -16,7 +16,7 @@ import TabItem from '@theme/TabItem'; -This page describes how to manage branches in the created component, whether it is an application, library, autotest or infrastructure. It also briefly explains two approaches of managing custom pipelines for codebases. +This page describes how to manage branches in the created Project, whether it is an application, library, autotest or infrastructure. It also briefly explains two approaches of managing custom pipelines for codebases.
@@ -39,7 +39,7 @@ Follow this approach if you need to define multiple similar applications with id ### Codebase Branch Settings -This approach involves creating a component with Tekton pipelines and selecting it in the codebase branch settings. +This approach involves creating a Project with Tekton pipelines and selecting it in the codebase branch settings. In contrast to the approach based on [build tool and framework](../use-cases/tekton-custom-pipelines.md), this one offers two main advantages: @@ -54,37 +54,29 @@ If you need to frequently and quickly redefine a build or review pipeline, this When working with libraries, pay attention to specifying the branch name: the branch name is involved in the formation of the library version, so it must comply with the [semantic versioning](https://semver.org/) rules for the library. ::: -When adding a component, the default branch is **main**. To add a new branch, follow the steps below: +When adding a Project, the default branch is **main**. To add a new branch, follow the steps below: -1. Navigate to the **Branches** block by clicking the component name link in the Components list and click the **+ Create branch** button: - - ![Add branch](../assets/user-guide/components/branches/branches-addbranch.png "Add branch") +1. Navigate to the **Branches** block by clicking the Project name link in the Projects list and click the **+ Create branch** button: 2. Fill in the required fields to create a new branch: - ![New branch](../assets/user-guide/components/branches/branches-create-new-branch.png "New branch") - - a. **Learn more** - opens a documentation page the explains how to add a new branch. - - b. **Release branch** - select this option to make a release branch. Codebases from release branches are marked with a different tag. - - :::note - When working with release branches, keep in mind that only the **semver** versioning type supports release branches. In the **default** versioning type, this option is unavailable. - Additionally, the SNAPSHOT version is reset each time you create a release branch. - ::: + **Release branch** - select this option to make a release branch. Codebases from release branches are marked with a different tag. - When the **Release branch** option is selected, you will also need to specify release tag the application will be marked: + :::note + When working with release branches, keep in mind that only the **semver** versioning type supports release branches. In the **default** versioning type, this option is unavailable. + Additionally, the SNAPSHOT version is reset each time you create a release branch. + ::: - ![Release branch](../assets/user-guide/components/branches/branches-release-branch.png "Release branch") + When the **Release branch** option is selected, you will also need to specify release tag the Codebase will be marked: - c. **Branch name** - type the branch name. + **Branch name** - type the branch name. :::note The **Branch name** field remains static if you create a release branch. If you want to onboard an existing branch, enter the name of the existing branch in the **Branch name** fields. ::: - d. **From** - by default, the KubeRocketCI portal will suggest creating a branch from the main branch. If you want to create a branch from another branch or commit hash, change this field: + **From** - by default, the KubeRocketCI portal will suggest creating a branch from the main branch. If you want to create a branch from another branch or commit hash, change this field: In the **From** field, select the **Branch** option. In the field to the right, specify the name of the source branch you want to create a branch from: - ![Create branch from another branch](../assets/user-guide/components/branches/branches-create-new-branch-from-branch.png "Create branch from another branch") - - e. **Branch version** - specify the application version and tag (SNAPSHOT by default). + **Branch version** - specify the application version and tag (SNAPSHOT by default). + + **Build pipeline** - select the build pipeline you want to use to build the application or leave the default one. - f. **Build pipeline** - select the build pipeline you want to use to build the application or leave the default one. + **Review pipeline** - select the review pipeline you want to use to review the application or leave the default one. - g. **Review pipeline** - select the review pipeline you want to use to review the application or leave the default one. +3. Click **Create**. - h. **View diagram** - view the pipeline to verify this is the exact pipeline you need: +Use additional tools to get guidance for the process: - ![View pipeline diagram](../assets/user-guide/components/branches/branches-pipeline-diagram.png "View pipeline diagram") +- **View diagram**: Visualizes the selected pipeline to make sure it matches your needs. +- **Form Guide**: Shows details about each field of the form. :::note To get the most out of managing build/review pipelines via KubeRocketCI portal, you should follow the **Add-Ons** approach for pipeline management. ::: -3. Click **Edit YAML** in the upper-right corner of the dialog to open the YAML editor and add a branch. Otherwise, fill in the required fields in the dialog: - - ![Yaml edit](../assets/user-guide/components/branches/branches-yaml-edit.png "Yaml edit") - :::info Adding of a new branch is indicated in the context of the `semver` versioning type. ::: @@ -141,19 +128,12 @@ Onboarding a branch that has already been created in Git to the platform follows To edit branch properties, follow the steps below: -1. Navigate to the **Branches** block by clicking the component name link in the components list. - -2. Click the actions button and select **Edit**: - - ![Edit branch](../assets/user-guide/components/branches/branches-edit-branch.png "Edit branch") +1. Navigate to the **Branches** block by clicking the Project name link in the Project list. -3. Change the branch options and click **Apply**: +2. Click the actions button and select **Edit**. - ![Select pipeline](../assets/user-guide/components/branches/branches-set-pipelines.png "Select pipeline") +3. Change the branch options and click **Apply**. - a. Select another pipeline from the drop-down list. - - b. Click the **View diagram** button. ## Build Branch @@ -161,25 +141,12 @@ In order to build branch from the latest commit, do the following: 1. Navigate to the **Branches** block by clicking the library name link in the Libraries list. -2. Click the **Build** button: - - ![Build branch](../assets/user-guide/components/branches/branches-build-branch.png "Build branch") - -The pipeline run status is displayed near the branch name in the **Branches** block: +2. Click the **Build** button. - ![Pipeline run status in KubeRocketCI portal](../assets/user-guide/components/branches/branches-pipeline-run-status.png "Pipeline run status in KubeRocketCI portal") +The pipeline run status is displayed near the branch name in the **Branches** block.The corresponding item appears in the **Pipelines** section. -The corresponding item appears in the **Pipelines** section: +As an alternative way, click the **tree diagram** icon to observe the real-time status of the pipeline run. - ![Pipeline run status](../assets/user-guide/components/branches/branches-pipelineruns-list.png "Pipeline run status") - -As an alternative way, click the tree diagram icon to observe the real-time status of the pipeline run: - - ![Tree diagram icon](../assets/user-guide/components/branches/branches-tree-diagram-icon.png "Tree diagram icon") - -The tree diagram window is presented below: - - ![Tree diagram window](../assets/user-guide/components/branches/branches-tree-diagram-window.png "Tree diagram window") ## Delete Branch @@ -190,16 +157,12 @@ The tree diagram window is presented below: In order to delete the added branch with the corresponding record in the KubeRocketCI portal database, do the following: -1. Click the component name link in the components list. +1. Click the Project name link in the Projects list. 2. Select the **Branches** tab. -2. Define the branch you want to delete. -3. On the branch block, click the actions button and select **Delete**: - - ![Delete branch](../assets/user-guide/components/branches/branches-delete-branch.png "Delete branch") - -4. Confirm deletion of the branch by typing its name and clicking **Confirm**: +3. Define the branch you want to delete. +4. On the branch block, click the actions button and select **Delete**. +5. Confirm deletion of the branch by typing its name and clicking **Confirm**. - ![Confirm deletion](../assets/user-guide/components/branches/branches-confirm-deletion.png "Confirm deletion") ## Related Articles diff --git a/docs/user-guide/manage-container-registries.md b/docs/user-guide/manage-container-registries.md index 4f90be69a0..f87393f83f 100644 --- a/docs/user-guide/manage-container-registries.md +++ b/docs/user-guide/manage-container-registries.md @@ -34,9 +34,7 @@ The following table displays the registry services supported for both OpenShift Follow a three-step process to integrate a container registry in KubeRocketCI: -1. In the **Configuration** -> **Artifacts storage** -> **Registry** click the **+ Add Registry** button: - - ![Registry settings](../assets/operator-guide/container-registry-list.png "Registry settings") +1. In the **Configuration** -> **Artifacts storage** -> **Registry** click the **+ Add Registry** button. 2. Select **Registry Provider** and enter the required details. @@ -55,7 +53,6 @@ Follow a three-step process to integrate a container registry in KubeRocketCI: ]}> - ![AWS ECR settings](../assets/operator-guide/container-registry-ecr.png "AWS ECR settings") |Fields|Description| |:-|:-| @@ -66,7 +63,6 @@ Follow a three-step process to integrate a container registry in KubeRocketCI: - ![DockerHub settings](../assets/operator-guide/container-registry-dockerhub.png "DockerHub settings") |Fields|Description| |:-|:-| @@ -77,7 +73,6 @@ Follow a three-step process to integrate a container registry in KubeRocketCI: - ![Harbor settings](../assets/operator-guide/container-registry-harbor.png "Harbor settings") |Fields|Description| |:-|:-| @@ -89,7 +84,6 @@ Follow a three-step process to integrate a container registry in KubeRocketCI: - ![Nexus settings](../assets/operator-guide/container-registry-nexus.png "Nexus settings") |Fields|Description| |:-|:-| @@ -100,7 +94,6 @@ Follow a three-step process to integrate a container registry in KubeRocketCI: - ![GitHub container registry settings](../assets/operator-guide/container-registry-github.png "GitHub container registry settings") |Fields|Description| |:-|:-| @@ -111,20 +104,6 @@ Follow a three-step process to integrate a container registry in KubeRocketCI: -## Remove Container Registry - -To remove container registry integration from KubeRocketCI, follow the steps below: - -:::warning - Proceed with caution, removing registry settings might disrupt your CI/CD process. All new components created after changing the registry such as Components and Environments will start working out of the box. To work with existing codebases and pipelines familiarize with the [change container registry guide](change-container-registry.md). -::: - - 1. In the **Configuration** -> **Artifacts storage** -> **Registry**. - - 2. Click the **Reset registry** button, type the `confirm` word and then click **Confirm**: - - ![Registry settings](../assets/operator-guide/container-registry-reset.png "Registry settings") - ## Related Articles * [Install KubeRocketCI](../operator-guide/install-kuberocketci.md) diff --git a/docs/user-guide/manage-environments.md b/docs/user-guide/manage-environments.md index 33e5a116e5..188a8548fe 100644 --- a/docs/user-guide/manage-environments.md +++ b/docs/user-guide/manage-environments.md @@ -1,173 +1,150 @@ --- -title: "Manage Deployment Flows" -sidebar_label: "Manage Deployment Flows" -description: "Navigate deployment flow management in KubeRocketCI, from viewing details to editing, deleting, and troubleshooting deployment environments." +title: "Manage Deployments" +sidebar_label: "Manage Deployments" +description: "Navigate deployment management in KubeRocketCI, from viewing details to editing, deleting, and troubleshooting deployment environments." --- -# Manage Deployment Flows +# Manage Deployments -This page describes actions that can be performed to an already created deployment flow. If no deployment flows are created yet, navigate to the [Add Deployment Flow](add-cd-pipeline.md) page: +This page describes actions that can be performed to an already created Deployment. If no Deployments are created yet, navigate to the [Add Deployment](add-cd-pipeline.md) page. - ![Deployment flows page](../assets/user-guide/environments/edp-portal-cd-pipeline-page.png "Deployment flows page") +The added Deployment will be listed in the Projects list allowing you to do the following: -* **Deployment flow status** - displays the deployment flow status. Can be red or green depending on if the KubeRocketCI portal managed to connect to the Git Server with the specified credentials or not. -* **Deployment flow name** (clickable) - displays the Git Server name set during the Git Server creation. -* **Open documentation** - opens the [Add Deployment Flow](./add-cd-pipeline.md) page. -* **Enable filtering** - enables filtering by Git Server name and namespace where this deployment flow is located in. -* **Create new deployment flow** - displays the Create new component menu. -* **Edit deployment flow** - edit the deployment flow by selecting the options icon next to its name in the deployment flow list, and then selecting Edit. For details see the [Edit Existing Deployment Flow](#edit-existing-deployment-flow) section. -* **Delete deployment flow** - remove deployment flow by clicking the vertical ellipsis button and then selecting Delete. -* **Chat assistant** - opens the chat window with AI assistant. + * Observe it in the Projects list; + * Manage branches; + * Run build/review pipelines; + * View SonarQube/DefectDojo metrics; + * View Merge Requests; + * View Deployments this application is a part of. - :::note - Please keep in mind that after deleting the deployment flow, all the created resources within the deployment flow will be deleted. - ::: +The added Deployment will be listed in the Deployments list allowing you to do the following: -## View Deployment Flow Details +* **Deployment status** - displays the deployment status. Can be red or green depending on if the KubeRocketCI portal managed to connect to the Git Server with the specified credentials or not; +* **Deployment name** (clickable) - displays the Deployment name set during the Deployment creation; +* **Page guide** - runs the tour that briefly explains the page; +* **Enable filtering** - enables filtering by Deployment name and namespace where this deployment is located in; +* **+ Create new deployment** - opens the **Create new deployment** menu; +* **Configure** - edit the Deployment by clicking the vertical ellipsis button and then selecting **Configure**. For details see the [Edit Existing Deployment](#edit-existing-deployment) section; +* **Delete** - remove Deployment by clicking the vertical ellipsis button and then selecting **Delete**; -To view deployment flow details, click the deployment flow name in the deployment flows list. Once clicked, the following data will be displayed: + :::note + Please keep in mind that after deleting the deployment, all the created resources within the deployment will be deleted. + ::: - ![Deployment flow details](../assets/user-guide/environments/edp-portal-cd-pipeline-overview.png "Deployment flow details") +## View Deployment Details -* **Filters** - enables filtering by stage name, stage applications and stage health status. -* **Open deployment flow in Argo CD** - opens the corresponding resource in Argo CD. -* **Edit deployment flow** - allows to edit some parameters of the deployment flow. -* **Delete deployment flow** - allows to remove the deployment flow. -* **Create new stage** - displays the **Create stage** menu. -* **Stage name (clickable)** - opens the stage details page. -* **Stage status** - displays the status of the created stage. -* **Create new stage** - displays the **Create stage** menu. -* **Application name (clickable)** - opens the details of the application that is deployed within the stage. -* **Application deployment status** - displays the deployed application. -* **Open application logs** - opens the the application container logs. -* **Open application terminal** - opens the container terminal window. -* **Open application resource in Argo CD** - opens a new tab with Argo CD resources related to the application. -* **Open stage in Argo CD / Grafana / Kibana** - allows to view the stage in Argo CD, Grafana or Kibana. +To view deployment details, click the deployment name in the deployments list. Once clicked, the following data will be displayed: -### Edit Existing Deployment Flow +* **Open deployment in Argo CD** - opens the corresponding resource in Argo CD; +* **Actions** - allows to edit some parameters of the deployment or delete it; +* **+ Create environment** - displays the **Create new environment** menu; +* **Environment name (clickable)** - opens the Environment details page; +* **Environment status** - displays the status of the created Environment; +* **Application name (clickable)** - opens the details of the application that is deployed within the stage; +* **Application deployment status** - displays the deployed application; +* **Open application logs** - opens the the application container logs; +* **Open application terminal** - opens the container terminal window; +* **Argo CD** - opens a new tab with Argo CD resources related to the application; +* **Logging** - allows to view the stage in Grafana or Kibana. -Edit the deployment flow directly from the deployment flow overview page or when viewing the deployment flow data: +### Edit Existing Deployment -1. Select **Edit** in the options icon menu next to the deployment flow name: +Edit the deployment directly from the deployment overview page or when viewing the deployment data: - ![Edit deployment flow when viewing the deployment flow data](../assets/user-guide/environments/edp-portal-edit-cd-pipeline-1.png "Edit deployment flow when viewing the deployment flow data") +1. Select **Edit** in the options icon menu next to the deployment name. 2. Apply the necessary changes (edit the list of applications for deploy, application branches, and promotion in the pipeline). Add new extra stages by clicking the plus sign icon and filling in the application branch and promotion in the pipeline. - ![Edit deployment flow dialog](../assets/user-guide/environments/edp-portal-edit-cd-pipeline-page.png "Edit deployment flow dialog") - 3. Click the **Apply** button to confirm the changes. ### Add a New Environment -In order to create a new environment for the existing deployment flow, follow the steps below: - -1. Navigate to the **Environments** block by clicking the deployment flow name link in the deployment flows list. +In order to create a new environment for the existing deployment, follow the steps below: -2. Click the **Create environment** button: +1. Navigate to the **Environments** block by clicking the deployment name link in the deployments list. - ![Add environment button](../assets/user-guide/environments/edp-portal-cd-pipeline-add-stages.png "Add environment button") +2. Click the **+ Create environment** button. -3. Fill in the required fields in the dialog. Alternatively, click **Edit YAML** in the upper-right corner of the **Create environment** dialog to open the YAML editor and add an environment. Please see the [Stages Menu](../user-guide/add-cd-pipeline.md) section for details. +3. Fill in the required fields in the dialog. Please see the [Stages Menu](../user-guide/add-cd-pipeline.md#create-environment) section for details. 4. Click the **Apply** button. ### Edit Environment -In order to edit an environment for the existing deployment flow, follow the steps below: - -1. Click the environment name in the deployment flows list to enter its details page. +In order to edit an environment for the existing deployment, follow the steps below: -2. In the upper-right corner of the page, click the **Edit** button: +1. Click the Environment name in the Deployment details page. - ![Edit environment](../assets/user-guide/environments/edp-portal-edit-cd-pipeline-stage.png "Edit environment") +2. In the upper-right corner of the page, click the **Actions** button and select **Edit**. -3. In the **Edit environment** dialog, change the environment trigger type and deploy pipeline template: - - ![Edit environment dialog](../assets/user-guide/environments/edp-portal-edit-cd-pipeline-stage-dialog.png "Edit environment dialog") +3. In the **Edit environment** dialog, change the environment trigger type and deploy pipeline template. 4. Click the **Apply** button. ### Delete Environment :::warning - You cannot remove the last environment, as the deployment flow does not exist without at least one. + You cannot remove the last Environment, as the Deployment does not exist without at least one. :::: -In order to delete an environment for the existing deployment flow, follow the steps below: - -1. Navigate to the **Environments** block by clicking the deployment flow name link in the deployment flows list. - -2. Click the name of the environment that needs to be deleted: +In order to delete an Environment for the existing Deployment, follow the steps below: - ![Delete environment](../assets/user-guide/environments/enter_stage.png "Delete environment") +1. Navigate to the **Environments** block by clicking the Deployment name link in the Deployments list. -3. Click the recycle bin button to open the environment deletion menu: +2. Click the name of the Environment that needs to be deleted. - ![Delete environment button](../assets/user-guide/environments/edp-portal-delete-cd-pipeline-stage.png "Delete environment button") +3. In the upper-right corner of the page, click the **Actions** button and select **Edit**. -4. Enter the environment name and click **Confirm**: - - ![Confirm deletion](../assets/user-guide/environments/confirm-environment-deletion.png "Confirm deletion") +4. Enter the Environment name and click **Confirm**. ### View Environment Data To view the environment data for the existing environment, follow the steps below: -1. Navigate to the **Stages** block by clicking the deployment flow name link in the deployment flows list; - - ![Expand environment](../assets/user-guide/environments/edp-portal-expand-stage.png "Expand environment") +1. Navigate to the **Environments** block by clicking the Deployment name link in the Deployments list. 2. Click the environment name. The following blocks will be displayed: - ![Environment overview](../assets/user-guide/environments/edp-portal-stage-overview.png "Environment overview") - a. **Overview** - general information and configuration of current environment. b. **Applications** - displays the status of the applications related to the environment and allows for [deploying applications](#deploy-application). Applications health and sync statuses are returned from the Argo CD tool. c. **Pipelines** - displays all the deploy pipeline runs launched for this environment. - d. **Monitoring** - opens the Grafana window that allows for watching various metrics. + d. **Variables** - adds personalized variables that will be used in the deploy pipelines. + + e. **Monitoring** - opens the Grafana window that allows for watching various metrics. ### Deploy Application To deploy an application, follow the steps below: -1. Navigate to the **Applications** block and click the **Configure deploy** button: - - ![Configure deploy button](../assets/user-guide/environments/configure-deploy-button.png "Configure deploy button") +1. Navigate to the **Applications** block and click the **Configure deploy** button. 2. Set deployment properties you need: - ![Deploy the promoted application](../assets/user-guide/environments/deploy_application.png "Deploy the promoted application") + a. Select the image stream version from the drop-down list. - a. Select the image stream version from the drop-down list. + b. (Optional) Enable setting custom values for Helm Charts. For more details, please refer to the [Manage GitOps](gitops.md) page. - b. (Optional) Enable setting custom values for Helm Charts. For more details, please refer to the [Manage GitOps](gitops.md) page. + c. Click the **Start Deploy** button to start a pipeline with the deploy script. - c. Click the **Start Deploy** button to start a pipeline with the deploy script. - - :::info - In case of using OpenShift internal registry, if the deployment fails with the ImagePullBackOff error, delete the pod that was created for this application. - ::: + :::info + In case of using OpenShift internal registry, if the deployment fails with the ImagePullBackOff error, delete the pod that was created for this application. + ::: -To uninstall the application, click the **Delete** button: - -![Uninstall the application](../assets/user-guide/environments/edp-portal-uninstall-application.png "Uninstall the application") +To uninstall the application, click the **Delete** button. As a result, the application will be uninstalled in the Argo CD tool as well. -Alternatively, you can use the **Clean** button. This way will be appropriate when you have some specific requirements to the environment cleanup procedure. Note that you need to make up your own logic in the cleanup pipeline to use the button or choose one of the pre-defined pipelines offered by KubeRocketCI: - -![Clean up application](../assets/user-guide/environments/edp-portal-clean-application.png "Clean up application") +Alternatively, you can use the **Clean** button. This way will be appropriate when you have some specific requirements to the environment cleanup procedure. Note that you need to make up your own logic in the cleanup pipeline to use the button or choose one of the pre-defined pipelines offered by KubeRocketCI. ### Troubleshoot Application @@ -175,21 +152,13 @@ There is a couple of KubeRocketCI portal capabilities that will help in monitori To inspect the deployed application in KubeRocketCI portal, take the following steps: -1. Open the application logs by clicking the `Show Logs` button: - - ![Show Logs button](../assets/user-guide/environments/show_logs_button.png "Show Logs button") +1. Open the application logs by clicking the `Show Logs` button. -2. Inspect the shown logs: +2. Inspect the shown logs. - ![Inspect Logs](../assets/user-guide/environments/application_logs.png "Inspect Logs") +3. Open the application terminal by clicking the `Show Terminal` button. -3. Open the application terminal by clicking the `Show Terminal` button: - - ![Show Terminal button](../assets/user-guide/environments/show_terminal_button.png "Show Terminal button") - -4. Operate the terminal to fix the problem if any: - - ![Inspect application](../assets/user-guide/environments/application_terminal.png "Inspect application") +4. Operate the terminal to fix the problem if any. ### Monitor Application @@ -203,13 +172,9 @@ To monitor an application using Grafana, follow the steps below: 1. Navigate to the Environment details page. -2. In the Environment details page, open the **Monitoring** tab: +2. In the Environment details page, open the **Monitoring** tab. - ![Monitoring tab](../assets/user-guide/environments/monitoring-tab.png "Monitoring tab") - -3. In the **Monitoring** tab, view the deployment metrics: - - ![Grafana monitoring dashboard](../assets/user-guide/environments/grafana-monitoring-dashboard.png "Grafana monitoring dashboard") +3. In the **Monitoring** tab, view the Deployment metrics. The **Monitoring** tab provides the visual representation of the basic application deployment metrics, such as CPU and Memory requests and limits. @@ -217,14 +182,12 @@ The **Monitoring** tab provides the visual representation of the basic applicati There are two buttons on the environment page that can be utilized to delete application in the portal: - ![Clean button](../assets/operator-guide/edp-portal-clean-application.png "Clean button") - * **Delete** - Deletes selected applications and associated resources. * **Clean** - Manages custom cleanup actions, such as deleting cloud resources and databases, rolling back transactions, etc. The **Delete** button is optimized for applications based on a single, simple helm chart that can be deployed independently without any specific dependencies. -The **Clean** button activates a deletion process (triggers a delete pipeline) that includes any custom logic you have defined. This option is most suitable for applications that require complex configurations to function properly. It ensures that any associated resources with the same lifecycle are deleted when the application is no longer needed. +The **Clean** button activates a deletion process (triggers a delete pipeline) that includes any custom logic you have defined. It runs the Clean Pipeline template you chose when [adding a Deployment](./add-cd-pipeline.md#add-deployment). This option is most suitable for applications that require complex configurations to function properly. It ensures that any associated resources with the same lifecycle are deleted when the application is no longer needed. KubeRocketCI provides an intuitive and streamlined pipeline by default. Initially, there is no distinction between the **Delete** and **Clean** buttons, as both perform identical actions. This default behavior encompasses the straightforward deletion of applications, which involves the uninstallation of the associated Helm chart. However, this functionality evolves once a custom delete pipeline is established, enabling manual configuration of the logic behind the **Clean** button. This customization allows for a more tailored approach to managing application lifecycles within KubeRocketCI. diff --git a/docs/user-guide/manual-approval.md b/docs/user-guide/manual-approval.md index 7415963c69..be03db51f8 100644 --- a/docs/user-guide/manual-approval.md +++ b/docs/user-guide/manual-approval.md @@ -13,7 +13,7 @@ sidebar_label: "Manual Approval in Pipelines" The manual approval feature gives users a smooth and controlled process of promoting applications from lower, non-critical environments, such as development or QA, to mission-critical environments like production. Additionally, it ensures that only thoroughly tested and verified changes are deployed to production, minimizing the risk of causing errors or instability. -Manual approval, at its simplest, is an integrable Tekton [task](https://github.com/epam/edp-tekton/blob/v0.13.0/charts/pipelines-library/templates/pipelines/cd/deploy-with-approve.yaml#L61) that can be integrated into common Tekton pipelines. Its purpose is to pause pipeline execution until a user approves or rejects the task. +Manual approval, at its simplest, is an integrable Tekton [Task](https://github.com/epam/edp-tekton/blob/v0.13.0/charts/pipelines-library/templates/pipelines/cd/deploy-with-approve.yaml#L61) that can be integrated into common Tekton pipelines. Its purpose is to pause pipeline execution until a user approves or rejects the task. ## Prerequisites @@ -27,47 +27,33 @@ KubeRocketCI offers a pre-defined deploy pipeline called **deploy-with-approve** To apply the **deploy-with-approve** pipeline template to your environments, follow the steps below: -1. In the deployment flow details page, click the **Create environment** button: +1. In the deployment details page, click the **Create environment** button. - ![Create environment button](../assets/operator-guide/create-environment-button-deploy.png "Create environment button") - -2. In the **Create environment** window, select the **deploy-with-approve** pipeline: - - ![Select pipeline with approval](../assets/operator-guide/custom-approve-pipeline1.png "Select pipeline with approval") +2. When creating an Environment, select the **deploy-with-approve** pipeline in the [Pipeline Configuration](./add-cd-pipeline.md#pipeline-configuration) stage. ### Existing Environments If you need to change the default deploy pipeline template in an already existing environment, follow the steps below: -1. Navigate to the environment details page and click the **Edit** button: - - ![Edit environment button](../assets/operator-guide/edit-environment-button-deploy.png "Edit environment button") +1. Navigate to the environment details page and click the **Edit** button. -2. In the **Edit environment** window, select another deploy pipeline: +2. In the **Edit environment** window, select another deploy pipeline. - ![Select pipeline with approval](../assets/operator-guide/custom-approve-pipeline2.png "Select pipeline with approval") ## Approve/Reject Deployment Once the deploy pipeline has been launched and reached the approval step, you will see a corresponding notification on the pipeline details page: - ![Approve step](../assets/operator-guide/approve_step.png "Approve step") - -If the approval is rejected, the pipeline status will be failed: - - ![Manual approve rejected](../assets/operator-guide/manual_approve_rejected.png "Manual approve rejected") - -If you don’t make a selection within the pipeline processing time, which is **60 minutes** by default, you’ll see a crossed clock icon as the task run status, indicating that the pipeline has timed out: +If the approval is rejected, the pipeline status will be failed. - ![Approval timed out](../assets/operator-guide/manual_approve_timeout.png "Approval timed out") +If you don’t make a selection within the pipeline processing time, which is **60 minutes** by default, you’ll see a crossed clock icon as the task run status, indicating that the pipeline has timed out. :::note You can set a custom timeout duration in the relevant [TriggerTemplate](https://github.com/epam/edp-tekton/blob/v0.13.0/charts/pipelines-library/templates/triggers/cd/deploy-with-approve.yaml#L46). ::: -If you choose the **Approve** option, the pipeline will proceed running: +If you choose the **Approve** option, the pipeline will proceed running. - ![Pipeline approved](../assets/operator-guide/manual_approve_approved.png "Pipeline approved") ## Create Pipeline With Approval Task @@ -121,4 +107,4 @@ To create a deploy pipeline with a manual approval task, follow the steps below: * [Customize Environment Cleanup](../operator-guide/cd/customize-environment-deletion.md) * [Customize Deploy Pipeline](../operator-guide/cd/customize-deploy-pipeline.md) * [Add Deployment Flow](../user-guide/add-cd-pipeline.md) -* [Manage Deployment Flows](../user-guide/manage-environments.md) +* [Manage Deployments](../user-guide/manage-environments.md) diff --git a/docs/user-guide/observability.md b/docs/user-guide/observability.md new file mode 100644 index 0000000000..e5e2705b2c --- /dev/null +++ b/docs/user-guide/observability.md @@ -0,0 +1,49 @@ +--- +title: "Observability" +sidebar_label: "Observability" +description: "Monitoring, logging, and visibility into pipeline runs, application statuses, and platform metrics." +--- + + +# Observability + + + + + +The Observability section provides monitoring, logging, and visibility into pipeline runs, application statuses, and platform metrics. This page describes the main views and dashboards available under Observability. + +## Pipeline Metrics + +The **Pipeline Metrics** dashboard shows aggregated pipeline statistics for a chosen namespace. Use it to track run counts, success rates, failures, and duration over time. + +### Filters + +* **Select codebase** — Limit metrics to a specific codebase. +* **Time range** — Choose **Today**, **7 Days**, **30 Days**, or **90 Days** to scope the data. + +### Key Metrics + +* **Total Runs** — Number of pipeline runs in the selected period. +* **Success Rate** — Percentage of runs that succeeded (with count of succeeded runs). +* **Failed** — Number of failed runs (e.g. “All green” when there are no failures). +* **Avg Duration** — Average pipeline duration and the min–max range (e.g. 1m 40s – 1h 0m). + +### Pipeline Type Breakdown + +Metrics are split by pipeline type: + +* **Build Pipelines** — Source code builds: total runs, success rate, succeeded and failed counts. +* **Review Pipelines** — PR/MR reviews: same metrics. +* **Deploy Pipelines** — Environment deployments: same metrics. + +Use this section to see which type (build, review, or deploy) contributes to overall success or failure. + +### Pipeline Activity + +A timeline chart shows when pipelines ran and whether they succeeded or failed. The legend indicates **Succeeded** (e.g. teal) and **Failed** (e.g. red). Use it to spot busy hours and failure patterns over the selected time range. + +## Related Articles + +* [KubeRocketCI Widgets](./widgets.md) +* [CI/CD Pipelines](./pipelines.md) diff --git a/docs/user-guide/overview.md b/docs/user-guide/overview.md new file mode 100644 index 0000000000..72bfbe944d --- /dev/null +++ b/docs/user-guide/overview.md @@ -0,0 +1,84 @@ +--- +title: "Overview" +sidebar_label: "Overview" +description: "The main KubeRocketCI dashboard: pipeline metrics, resource health, activity, integrations, and quick links." +--- + + +# Overview + + + + + +The **Overview** page under **Platform** is the main dashboard for the selected cluster and namespace. It summarizes pipeline activity, resource health, recent work, usage, security and quality signals, integrations, and links to external tools. For a deeper description of individual widgets, see [KubeRocketCI Widgets](./widgets.md). + +## Summary Cards (Header) + +The top row gives a quick read on **today’s** pipeline health. Four cards show pipeline metrics for the current context: + +* **Total Pipeline Runs** — Number of runs today. +* **Success Rate** — Share of successful runs (or “no data” when there is nothing to show). +* **Failed Pipelines** — Count of failed runs. +* **Average Duration** — Average run duration (or “no data” when not applicable). + +## Pipeline Activity + +The **Pipeline Activity (7 days)** widget helps you see trends and spikes over the last week. It is a bar chart: each day is a bar split by outcome — **Succeeded** (e.g. green) and **Failed** (e.g. red) — so you can spot busy days and failure spikes at a glance. + +## Resource Health + +**Resource Health** is a strip of circular indicators so you can scan counts and status without opening other sections. Each circle summarizes one entity type: + +* **Codebases** — Number of codebases. +* **Branches** — Total branches across codebases. +* **Pipelines** — Pipeline-related count for the context. +* **CD Pipelines** — CD pipelines. +* **Stages** — Deployment stages. + +Use this strip to see whether core objects look healthy before drilling into **Projects**, **CI/CD Pipelines**, or **Deployments**. + +## Activity and Git + +The central column includes widgets for **what ran recently**, **your own runs**, and **Git-side activity**. They typically work as follows: + +* **Recent Pipeline Activity** — Latest pipeline runs; often includes **View All** to open the full list. Empty when there are no runs. +* **My Activity** — Runs associated with your account; **View All** when available. +* **Git Activity** — Pull request activity when connected; may show “no pull request data” if none is available. + +## Resource Usage + +On the right side, **Resource Usage** summarizes how much cluster capacity the platform workload is using and which pods stand out. You will usually see: + +* Totals or gauges for **CPU**, **Memory**, and **Pods**. +* A **top pods by CPU** (or similar) list with names and usage so you can spot heavy consumers. + +## Security and Quality + +Two widgets condense security and static-analysis posture for the current scope. They show: + +* **Vulnerability Summary** — Totals by severity (Critical, High, Medium, Low) from integrated vulnerability data (e.g. Dependency-Track). +* **SonarQube Quality** — Aggregated quality gate results for SonarQube projects linked to the platform. + +## Integrations + +**Integrations** lists external systems the portal talks to (Jira, registries, observability, and others). It is useful for spotting misconfiguration or downtime before you rely on a tool in a workflow. The widget may show counts such as how many connections need attention, short error text, and actions like **Fix** next to a failing integration. + +## DORA Metrics + +**DORA** widgets summarize delivery behavior over a fixed window (often the **last 30 days**). They support conversations about speed and stability. Typical fields are: + +* **Deployment Frequency** — Deploy count over the period, successes, and a simple cadence (e.g. average days between deploys). +* **Change Failure Rate** — Share of failed deploys vs total, sometimes with a status such as “Needs attention” when above a threshold. + +## Links + +The **Links** area at the bottom is a grid of shortcuts to integrated tools (Argo CD, Git providers, container registry, DefectDojo, Dependency-Track, SonarQube, Prometheus, Grafana, Kibana, Jaeger, Jira, Keycloak, Nexus, and others depending on your setup). Use **+ Add Link** to add custom entries; see [Manage Quick Links](./quick-links.md). + +## Related Articles + +These pages go deeper into areas that overlap with the Overview dashboard: + +* [KubeRocketCI Widgets](./widgets.md) +* [Observability](./observability.md) +* [Security](./security/sca-overview.md) diff --git a/docs/user-guide/pipelines.md b/docs/user-guide/pipelines.md index cf0b04e693..72e4342791 100644 --- a/docs/user-guide/pipelines.md +++ b/docs/user-guide/pipelines.md @@ -17,152 +17,50 @@ Pipelines are an integral part of any CI/CD. They are involved in code build, re ## Pipelines Page Overview -To see the Pipelines section, open the KubeRocketCI portal and select the **Pipelines** section: +To see the CI/CD Pipelines section, open the KubeRocketCI portal and select the **CI/CD Pipelines** section: - ![Pipelines overview](../assets/user-guide/pipelines/pipelines-overview.png "Pipelines overview") - -* **View and Manage PipelineRuns/Pipelines/Tasks/History** - Allows to navigate between the corresponding tabs of the section. -* **PipelineRun details** - Displays the following pages: - - * **Checkbox** - Click the check box to select the pipelines to delete. - * **Status** - Displays PipelineRun status. The status can be either successful (green) or failed (red). Hover over the status to view the description. - * **Run** - Displays the PipelineRun name. Click the name to view its details. - * **Pipeline** - Indicates which pipeline this PipelineRun belongs to. Click the pipeline name to view its details. - * **Pull Request** - Click the icon to see which pull request started this PipelineRun. - * **Started at** - Displays the time the pipeline was started. - * **Time** - Displays the total amount of time it took the pipeline to complete. - * **Diagram** - Click the icon to see the real-time pipeline diagram. - * **Actions** - This button allows for restarting and deleting PipelineRuns. - -* **Filters** - Filter PipelineRuns by name, namespace, and pipeline they belong to. -* **Delete PipelineRun** - Allows to delete the selected PipelineRuns. -* **Pagination menu** - Allows to navigate through the list of PipelineRuns. +* **PipelineRuns** - Shows the recent PipelineRuns. You can filter PipelineRuns by status, type, and Codebase it launched for; +* **Pipelines** - This tab allows to view and edit all the Tekton Pipelines created in the platform; +* **Tasks** - This tab allows to view and edit all the Tekton Tasks created in the platform. ## Pipeline Overview -To inspect pipeline details, follow the steps below: - -1. Click the PipelineRun name to view its details: - - ![PipelineRun name](../assets/user-guide/pipelines/click-pipeline-run-name.png "PipelineRun name") - -2. The first tab that appears when you click the PipelineRun name is the **Details** tab: - - ![Pipeline details](../assets/user-guide/pipelines/pipeline-details-tab.png "Pipeline details") - - This tab displays the PipelineRun status and logs. - -3. Navigate to the **Overview** tab: - - ![Pipeline overview](../assets/user-guide/pipelines/pipelines-overview-tab.png "Pipeline overview") - - In this tab, you can view the general information and resources that the pipeline is connected with. - -4. Navigate to the **View YAML** tab: - - ![Pipeline view YAML](../assets/user-guide/pipelines/pipelines-view-yaml-tab.png "Pipeline view YAML") - - This tab displays the YAML configuration of your pipeline. - -5. Navigate to the **Results** tab: - - ![Pipeline results](../assets/user-guide/pipelines/pipeline-results-tab.png "Pipeline results") - - This tab shows the resulting artifact that was built in the pipeline. - - There are also a couple of ways to view the build pipeline results: from the codebase details page and the Pipelines section: - - From the codebase details page: - - ![Pipeline results in codebase details page](../assets/user-guide/pipelines/results-in-codebase.png "Pipeline results in codebase details page") - - From the Pipelines section: - - ![Pipeline results in Pipelines section](../assets/user-guide/pipelines/results-in-pipelines-section.png "Pipeline results in Pipelines section") - -:::note -This tab is accessible only in Build Pipelines that produce artifacts. -::: +To inspect pipeline details, click the PipelineRun name: -6. Navigate to the **Diagram** tab: +* The **Details** tab displays the PipelineRun status and logs; +* The **View YAML** tab displays the YAML configuration of your pipeline. It also allows to view the general information and resources that the pipeline is connected with; +The **Diagram** tab displays the pipeline's real-time status. Click the task name to navigate to the corresponding task in the **Details** tab; +* The **Results** tab shows the resulting artifact that was built in the pipeline. Note that this tab is accessible only in Build Pipelines that produce artifacts. - ![Pipeline diagram](../assets/user-guide/pipelines/pipelines-diagram-tab.png "Pipeline diagram") - - The diagram displays the pipeline's real-time status. Click the task name to navigate to the corresponding task in the **Details** tab. +You can also view the build pipeline results from the codebase details page and the Pipelines section. ## Operate With Pipelines The Pipelines section allows you to track, restart, and delete pipelines. -To restart the PipelineRun, click the actions button and select **Run again**: - - ![Restart PipelineRun](../assets/user-guide/pipelines/restart-pipeline-run.png "Restart PipelineRun") - -To restart the PipelineRun using different parameters, click the actions button and select **Run with params**: - - ![Restart with parameters](../assets/user-guide/pipelines/restart-with-parameters.png "Restart with parameters") - -To delete the PipelineRun, click the actions button and select **Delete**: - - ![Delete PipelineRun](../assets/user-guide/pipelines/delete-pipeline-run.png "Delete PipelineRun") - -Alternatively, you can enter the PipelineRun and delete/restart the pipeline using the corresponding buttons: - - ![Rerun/delete PipelineRun](../assets/user-guide/pipelines/restart-or-delete-pipeline.png "Rerun/delete PipelineRun") - -## View Pipelines/Tasks - -The Pipelines section also offers users to view and edit all the Tekton Pipelines and Tasks defined in the platform. It is implemented by the corresponding **Pipelines** and **Tasks** tabs. - -To view and manage Tekton Pipelines, select the **Pipelines** tab: - - ![Pipelines tab](../assets/user-guide/pipelines/pipelines-tab.png "Pipelines tab") +To restart the PipelineRun, click the actions button and select **Run again**. -To view and manage Tekton Tasks, select the **Tasks** tab: +To restart the PipelineRun using different parameters, click the actions button and select **Run with params**. - ![Tasks tab](../assets/user-guide/pipelines/tasks-tab.png "Tasks tab") +To delete the PipelineRun, click the actions button and select **Delete**. -The **History** tab shows logs saved in the alternative log stash tools, such as OpenSearch: - - ![History tab](../assets/user-guide/pipelines/history-tab.png "History tab") +Alternatively, you can enter the PipelineRun and delete/restart the pipeline using the corresponding buttons. :::note -The **History** tab operates if the OpenSearch tool is installed. You can install OpenSearch using our [cluster add-ons](https://github.com/epam/edp-cluster-add-ons/blob/main/clusters/core/apps/values.yaml#L207). +There is also an option to store the long-term logs using the OpenSearch tool. You can install OpenSearch using our [cluster add-ons](https://github.com/epam/edp-cluster-add-ons/blob/main/clusters/core/apps/values.yaml#L227) repository. ::: -## Edit Table View - -All the tables in the section are configurable. Most of the tabs can be hidden. To set only specific columns to display, click the **Table settings** button: - - ![Table settings button](../assets/user-guide/pipelines/table-settings-button.png "Table settings button") - -Select the columns to display and click **Save**: - - ![Table settings window](../assets/user-guide/pipelines/table-settings-window.png "Table settings window") - -You can also edit column width: - - ![Edit column width](../assets/user-guide/pipelines/edit-table-width.png "Edit column width") - -To reset table settings to defaults, select all the columns to display. - ## Edit Pipelines/Tasks KubeRocketCI portal allows to edit the existing Tekton Pipelines and Tasks directly in the Pipelines section. In our example, we will show how to edit a Task but the same procedure applies to Pipelines: 1. Navigate to the **Tasks** tab. -2. Enter a Task by clicking its name: - - ![Click PipelineRun name ](../assets/user-guide/pipelines/click-pipeline-run-name.png "Click PipelineRun name") - -3. On the Task details page, click **Edit**: - - ![Edit button](../assets/user-guide/pipelines/edit-task-button.png "Edit button") +2. Enter a Task by clicking its name. -4. On the edit window, make your changes and click **Save & apply**: +3. On the Task details page, in the top right corner of the screen, click **Edit**. - ![Edit Tekton Task](../assets/user-guide/pipelines/edit-task-window.png "Edit Tekton Task") +4. On the edit window, make your changes and click **Saved**. Now you know how to view and manage pipelines in KubeRocketCI. diff --git a/docs/user-guide/platform-cleanup-guide.md b/docs/user-guide/platform-cleanup-guide.md index b762a70d78..54f80be309 100644 --- a/docs/user-guide/platform-cleanup-guide.md +++ b/docs/user-guide/platform-cleanup-guide.md @@ -29,13 +29,13 @@ To follow the guidelines below, ensure you have: ## Platform Resource Cleanup -This section covers platform resource removal, such as components, deployment flows, and pipeline runs. +This section covers platform resource removal, such as components, deployments, and pipeline runs. -### Delete Deployment Flows +### Delete Deployments -Platform cleanup starts with deleting [deployment flows](add-cd-pipeline.md), a core resource that allows the platform to build an automated workflow. Deleting a deployment flow will delete applications from its associated cluster. +Platform cleanup starts with deleting [deployments](add-cd-pipeline.md), a core resource that allows the platform to build an automated workflow. Deleting a deployment will delete applications from its associated cluster. -We recommend cleaning environments before deleting deployment flows to ensure graceful resource deletion and avoid potential issues. +We recommend cleaning environments before deleting deployments to ensure graceful resource deletion and avoid potential issues. There are two strategies for cleaning environments: @@ -45,56 +45,38 @@ There are two strategies for cleaning environments: To delete an environment using the **Delete** button, read the [Manage Environments](manage-environments.md#delete-environment) page. :::note - A deployment flow must include at least one environment. + A deployment must include at least one environment. ::: -Once the environments are deleted, proceed with deleting a deployment flow. To delete a [deployment flow](./manage-environments.md), follow these steps: +Once the environments are deleted, proceed with deleting a deployment. To delete a [deployment](./manage-environments.md), follow these steps: -1. Navigate to **KubeRocketCI portal** -> **Deployment flows**: +1. Navigate to **KubeRocketCI portal** -> **Deployments**. - ![Deployment flows list](../assets/user-guide/deployment-flows.png "Deployment flows list") +2. Choose a deployment to delete. Click the actions button and select **Delete**. -2. Choose a deployment flow to delete. Click the actions button and select **Delete**: - - ![Delete deployment flow](../assets/user-guide/delete-deployment-flow.png "Delete deployment flow") - -3. Enter the deployment flow name and click **Delete**: - - ![Confirm deployment flow deletion](../assets/user-guide/confirm-deployment-flow-deletion.png "Confirm deployment flow deletion") +3. Enter the deployment name and click **Delete**. ### Delete Codebases -After deleting deployment flows, you can delete the associated resources they operate with. These resources, collectively referred to as codebases, include [applications](application.md), [libraries](library.md), [autotests](autotest.md), and [infrastructures](infrastructure.md). +After deleting deployments, you can delete the associated resources they operate with. These resources, collectively referred to as codebases, include [applications](application.md), [libraries](library.md), [autotests](autotest.md), and [infrastructures](infrastructure.md). In this example, we will demonstrate how to delete an application. The same procedure applies to other types of codebases: -1. Navigate to **KubeRocketCI portal** -> **Components**: - - ![Components list](../assets/user-guide/components-list.png "Components list") - -2. Choose an application to delete. Click the actions button and select **Delete**: +1. Navigate to **KubeRocketCI portal** -> **Projects**. - ![Delete component](../assets/user-guide/delete-component.png "Delete component") +2. Choose an application to delete. Click the actions button and select **Delete**. -3. Enter the application name and click **Delete**: - - ![Confirm codebase deletion](../assets/user-guide/confirm-application-deletion.png "Confirm codebase deletion") +3. Enter the application name and click **Delete**. ### Delete Pipeline Runs The last platform resource remaining is [pipeline runs](./pipelines.md). A pipeline run refers to an execution instance of a pipeline. Each time you trigger a build, review, deploy, or clean pipeline, a new pipeline run emerges. To delete pipeline runs, follow these steps: -1. Navigate to **KubeRocketCI portal** -> **Pipelines**: - - ![Pipelines list](../assets/user-guide/pipelines-list.png "Pipelines list") - -2. Choose pipeline runs and click **Delete**: +1. Navigate to **KubeRocketCI portal** -> **CI/CD Pipelines**. - ![Inspect application](../assets/user-guide/delete-pipeline-runs.png "Inspect application") +2. Choose pipeline runs and click **Delete**. -3. On the confirmation window, enter **confirm** and click **Delete**: - - ![Inspect application](../assets/user-guide/confirm-pipeline-runs-deletion.png "Inspect application") +3. On the confirmation window, enter **confirm** and click **Delete**. ## Third-Party Resource Cleanup @@ -186,7 +168,7 @@ To clean up unnecessary application binaries manually, follow these steps: ### Delete Container Images -KubeRocketCI uses container images to deploy the applications to [deployment flows](../user-guide/add-cd-pipeline.md). To clean up a container registry, follow the corresponding guidelines: +KubeRocketCI uses container images to deploy the applications to [deployments](../user-guide/add-cd-pipeline.md). To clean up a container registry, follow the corresponding guidelines: /.ssh/ 5. Verify you can access KubeRocketCI resources. -## Community Button +## User Details -Click the **Community** button to access helpful resources and support options: +On the **User Details** window, you can view your personal information: - ![Community button](../assets/user-guide/portal/community-button.png "Community button") +* **Name**: your Keycloak username; +* **Email**: your Keycloak user email; +* **Subject**: your Keycloak user ID; +* **Issuer URL**: the URL of the Keycloak realm that handles authorization; +* **Groups**: your Keycloak group membership. -When clicked, the following options are displayed: +## User Profile - ![Community options](../assets/user-guide/portal/community-options.png "Community options") +Click the User profile button in the bottom left corner of the screen to access helpful resources and support options. + +When clicked, the following options are displayed: * **Documentation**: opens the product documentation site; * **Join discussions**: opens the GitHub Discussions page for the product, where you can participate in community conversations; -* **Open an issue/request**: Opens the GitHub page where you can create a new issue or feature request for the product. +* **Open an issue/request**: Opens the GitHub page where you can create a new issue or feature request for the product; +* **Log out**: terminates the session and redirects you to the login page. + +:::note + The profile picture is also pulled from Keycloak. +::: ## Related Articles diff --git a/docs/user-guide/protected-label.md b/docs/user-guide/protected-label.md index 1ca0454b0e..6e1e57f23c 100644 --- a/docs/user-guide/protected-label.md +++ b/docs/user-guide/protected-label.md @@ -2,7 +2,7 @@ title: "Protect Resources From Deletion/Modification" sidebar_label: "Protect Resources From Deletion/Modification" -description: "Learn how to use the protected label feature in KubeRocketCI to prevent accidental deletion or modification of resources such as codebases, environments, and deployment flows." +description: "Learn how to use the protected label feature in KubeRocketCI to prevent accidental deletion or modification of resources such as codebases, environments, and deployments." --- @@ -23,7 +23,7 @@ Protected labels support the following resources: * [Codebases](../api/codebase.md#codebase); * [Codebase branches](../api/codebase.md#codebasebranch); -* [Deployment flows](../api/cd-pipeline.md#cdpipeline); +* [Deployments](../api/cd-pipeline.md#cdpipeline); * [Environments](../api/cd-pipeline.md#stage). ## Protection Types @@ -38,37 +38,25 @@ Protection label can optionally block specific operations over a resource: To apply the resource deletion and modification block, follow the steps below. We will use a codebase resource as an example, but the procedure applies to all the supported resources: -1. Navigate to the KubeRocketCI portal. +1. Open the terminal which has access to the cluster that runs KubeRocketCI. -2. Switch the portal to the Kubernetes mode: +2. Get the codebase list: - ![Kubernetes mode](../assets/user-guide/components/protected-label/kubernetes-mode.png "Kubernetes mode") + ```bash + kubectl get codebase -n krci + ``` -3. Navigate to **Cluster** -> **Custom resources**: +3. Define the codebase you want to protect from accidental deletion and/or modification. - ![Custom resources tab](../assets/user-guide/components/protected-label/custom-resources.png "Custom resources tab") +4. Enter the resource edit menu: -4. In the custom resources list, enter **Codebase** in the filter field to find it and then select it in the list: + ```bash + kubectl edit codebase -n krci + ``` - ![Codebase resource type](../assets/user-guide/components/protected-label/select-codebase.png "Codebase resource type") +5. In the labels section of the codebase specifications, add the label from the [Protection Types](#protection-types) list. -5. Enter the codebase you want to protect from accidental deletion and/or modification. - -6. On the resource details page, click the **Edit** button: - - ![Edit button](../assets/user-guide/components/protected-label/edit-codebase.png "Edit button") - -7. In the edit resource window, add the label to the **labels** section and click **Save and apply**: - - ![Add label](../assets/user-guide/components/protected-label/add-label.png "Add label") - -8. Make sure the label was applied: - - ![Verify label](../assets/user-guide/components/protected-label/verify-label.png "Verify label") - -9. Switch back to the KubeRocketCI mode, navigate to the **Components** section and verify that you can't delete or edit the protected codebase: - - ![Deletion/Modification is locked](../assets/user-guide/components/protected-label/deletion-locked.png "Deletion/Modification is locked") +6. Save and quit the menu. ## Remove Protected Label @@ -79,4 +67,4 @@ To remove a label, navigate back to the resource, edit the resource by removing * [Manage Applications](../user-guide/application.md) * [Customize Deploy Pipeline](../operator-guide/cd/customize-deploy-pipeline.md) * [Add Deployment Flow](../user-guide/add-cd-pipeline.md) -* [Manage Deployment Flows](../user-guide/manage-environments.md) +* [Manage Deployments](../user-guide/manage-environments.md) diff --git a/docs/user-guide/quick-links.md b/docs/user-guide/quick-links.md index 946e42689e..cdea4ab658 100644 --- a/docs/user-guide/quick-links.md +++ b/docs/user-guide/quick-links.md @@ -26,17 +26,11 @@ There are two methods to add Quick Links: To add a Quick Link via the KubeRocketCI portal, follow the steps below: -1. Navigate to **Configuration** -> **Quick Access** -> **Links** and click the **+ Add Link** button: +1. Navigate to **Configuration** -> **Quick Access** -> **Links** and click the **+ Add Link** button. - ![Links section](../assets/user-guide/links_section.png "Links section") +2. In the appeared window, insert the link name, URL, and SVG icon in base 64 format. -2. In the appeared window, insert the link name, URL, and SVG icon in base 64 format. Click the checkbox if it should be displayed on the **Overview** page: - - ![Create reference menu](../assets/user-guide/create_link_menu.png "Create reference menu") - -3. If the **Show on Overview Page** option is selected, the link will be displayed on the **Overview** page: - - ![Added link](../assets/user-guide/links_on_the_overview.png "Added link") +3. If the **Show on Overview Page** option is selected, the link will be displayed on the **Overview** page. ### Add Quick Link via Helm Chart @@ -110,13 +104,9 @@ After specifying the necessary Quick Links in the `values.yaml` file, the Quick To edit a Quick Link, follow the steps below: -1. Navigate to **Configuration** -> **Quick Access** -> **Links**. Click the three-dot menu and select **Edit**: - - ![Edit link button](../assets/user-guide/edit_link_button.png "Edit link button") +1. Navigate to **Configuration** -> **Quick Access** -> **Links**. Click the Actions menu and select **Edit**. -2. Edit the necessary fields and click **Apply**: - - ![Edit link menu](../assets/user-guide/edit_link_menu.png "Edit link menu") +2. Edit the necessary fields and click **Apply**. ## Delete Quick Link @@ -126,13 +116,9 @@ Quick Links of type **system** cannot be deleted as they are crucial for the pla To delete a Quick Link, follow the steps below: -1. Navigate to **Configuration** -> **Quick Access** -> **Links**. Click the three-dot menu and select **Delete**: - - ![Delete link button](../assets/user-guide/delete_link_button.png "Delete link button") - -2. In the **Confirm deletion** window, enter the name of the link and click **Confirm**: +1. Navigate to **Configuration** -> **Quick Access** -> **Links**. Click the Actions menu and select **Delete**. - ![Delete link menu](../assets/user-guide/delete_link_menu.png "Delete link menu") +2. In the **Confirm deletion** window, enter the name of the link and click **Confirm**. ## Related Articles diff --git a/docs/user-guide/security.md b/docs/user-guide/security.md new file mode 100644 index 0000000000..472a9aae5f --- /dev/null +++ b/docs/user-guide/security.md @@ -0,0 +1,14 @@ +--- +title: "Security" +sidebar_label: "Security" +description: "Security settings, access control, secrets management, and protected resources in the platform." +--- + + +# Security + + + + + +The Security section is documented under its sub-sections. For the main overview and SCA portfolio dashboard, see **[SCA Overview](security/sca-overview)**. diff --git a/docs/user-guide/security/cluster-compliance.md b/docs/user-guide/security/cluster-compliance.md new file mode 100644 index 0000000000..b413c92f60 --- /dev/null +++ b/docs/user-guide/security/cluster-compliance.md @@ -0,0 +1,77 @@ +--- +title: "Cluster Compliance" +sidebar_label: "Compliance" +description: "Kubernetes security compliance benchmarks (CIS, NSA, PSS) for the cluster." +--- + + +# Cluster Compliance + + + + + +**Cluster Compliance Reports** under **Security > Cluster Security > Compliance** show Kubernetes security compliance benchmarks (CIS, NSA, PSS) for the selected cluster. You can open each report to see the pass rate, severity breakdown, and individual controls. + +## Cluster Compliance Reports + +The page title is **Cluster Compliance Reports**, with a short description: *Kubernetes security compliance benchmarks (CIS, NSA, PSS)*. + +### Table + +Use the **Columns** control (e.g. "Columns 7") to choose which columns are visible. The table includes: + +| Column | Description | +|--------------|-------------| +| **Title** | Full name of the compliance standard (e.g. National Security Agency - Kubernetes Hardening Guidance v1.0, Kubernetes Pod Security Standards - Restricted/Baseline, AWS EKS CIS Foundations v1.4). | +| **Type** | Short type label with a colored badge: **NSA**, **PSS-RESTRICTED**, **PSS-BASELINE**, **CIS**. | +| **Version** | Version of the standard (e.g. 1.0, 0.1). | +| **Pass** | Number of passed checks (e.g. 27, 17, 11, 48). | +| **Fail** | Number of failed checks (dash when zero). | +| **Pass Rate**| Percentage of passed checks (e.g. 100%, 94%). | +| **Actions** | **View Details** button to open the full report. | + +**Pagination** at the bottom (e.g. "Rows per page: 25", "1–4 of 4") and navigation arrows let you move through the list. Click **View Details** on a row to open the report for that benchmark. + +## Report Details + +When you open a report, the breadcrumbs show **Security > Cluster Security > Compliance > <benchmark name>** (e.g. *National Security Agency - Kubernetes Hardening Guidance v1.0*). + +### Header + +Header contains the following information: + +* **Report title** — Full benchmark name and optional subtitle; often a link to the source (e.g. nsa.gov). +* **Overall status** — **Pass Rate** (e.g. 100%) in a bar, and summary **Passed** / **Failed** counts (e.g. "27 Passed", "0 Failed") with icons. + +### Severity Breakdown + +Four cards summarize controls by severity: + +* **Critical** — Count and status (e.g. "8", "All passed"). +* **High** — Count and status (e.g. "5", "All passed"). +* **Medium** — Count and status (e.g. "11", "All passed"). +* **Low** — Count and status (e.g. "3", "All passed"). + +### Compliance Controls Table + +Above the table you can filter by **Severity** (e.g. "All severities") and **Status** (e.g. "All"). The **Columns** button customizes visible columns. + +The table lists each control: + +| Column | Description | +|--------------|-------------| +| **Control ID** | Identifier (e.g. 3.0, 5.0, 5.1, 6.0, 1.2, 8.0). | +| **Name** | Short name of the control (e.g. "Use CNI plugin that supports NetworkPolicy API (Manual)", "Encrypt etcd communication", "Make sure -authorization-mode=RBAC"). | +| **Severity** | Critical, High, Medium, or Low. | +| **Status** | Pass or Fail. | +| **Failures** | Details of failures (dash when passed). | + +Use this view to see which controls passed or failed and to plan remediation. **Pagination** at the bottom (e.g. "Rows per page: 25") applies when there are many controls. + +## Related Articles + +* [Cluster Configuration Audits](./cluster-configuration-audits.md) +* [Cluster RBAC Assessments](./cluster-rbac-assessments.md) +* [Cluster Infrastructure Assessments](./cluster-infrastructure-assessments.md) +* [Cluster Vulnerability Reports](./cluster-vulnerability-reports.md) diff --git a/docs/user-guide/security/cluster-configuration-audits.md b/docs/user-guide/security/cluster-configuration-audits.md new file mode 100644 index 0000000000..5b8593012a --- /dev/null +++ b/docs/user-guide/security/cluster-configuration-audits.md @@ -0,0 +1,44 @@ +--- +title: "Cluster Configuration Audits" +sidebar_label: "Configuration Audits" +description: "Cluster-wide configuration audit security assessments." +--- + + +# Cluster Configuration Audits + + + + + +**Cluster Configuration Audit Reports** under **Security > Cluster Security > Configuration Audits** show cluster-wide configuration audit security assessments. Unlike [Namespace Configuration Audits](namespace-configuration-audits), the scope is the whole cluster, not a single namespace. You can open each report to see failed checks, descriptions, and remediation steps. Reports are generated by **Trivy**; they appear in the list once cluster resources have been scanned. + +## Cluster Configuration Audit Reports + +The page title is **Cluster Configuration Audit Reports**, with a short description: *Cluster-wide configuration audit security assessments*. There is no namespace filter — the list covers all audited entities at cluster level. + +### Table + +Use the **Columns** control (e.g. "Columns 7") above the table to choose which columns are visible. The table includes: + +| Column | Description | +|-----------------|-------------| +| **Name** | Name of the audited cluster resource or entity. | +| **Critical** | Number of critical findings. | +| **High** | Number of high-severity findings. | +| **Medium** | Number of medium-severity findings. | +| **Low** | Number of low-severity findings. | +| **Total Checks**| Total number of checks run. | + +If no cluster configuration audit reports exist yet, the page shows a message that no reports were found and that **Trivy cluster configuration audit reports will appear here once cluster resources are scanned**. **Pagination** at the bottom (e.g. "Rows per page: 25", "0 of 0") and navigation arrows let you move through the list when reports are present. Each row typically has an action (e.g. eye icon) to open **Audit Details**. + +## Audit Details + +When you open a report, the breadcrumbs show **Security > Cluster Security > Configuration Audits > Audit Details**. The detail view follows the same pattern as [Namespace Configuration Audits](namespace-configuration-audits#audit-details): a header with the audited resource, scan summary (checks passed/failed, scanner version, last scan), severity counts, and a table of findings. You can filter by **Severity** and **Status**, and expand each row to see **Description**, **Messages**, and **Remediation**. The only difference is that the audit applies to cluster-level resources rather than a single namespace. + +## Related Articles + +* [Namespace Configuration Audits](./namespace-configuration-audits.md) +* [Cluster RBAC Assessments](./cluster-rbac-assessments.md) +* [Cluster Infrastructure Assessments](./cluster-infrastructure-assessments.md) +* [Cluster Vulnerability Reports](./cluster-vulnerability-reports.md) diff --git a/docs/user-guide/security/cluster-infrastructure-assessments.md b/docs/user-guide/security/cluster-infrastructure-assessments.md new file mode 100644 index 0000000000..33b3b39614 --- /dev/null +++ b/docs/user-guide/security/cluster-infrastructure-assessments.md @@ -0,0 +1,73 @@ +--- +title: "Cluster Infrastructure Assessments" +sidebar_label: "Infrastructure Assessments" +description: "Cluster-wide infrastructure security assessments for cluster resources." +--- + + +# Cluster Infrastructure Assessments + + + + + +**Cluster Infrastructure Assessment Reports** under **Security > Cluster Security > Infrastructure Assessments** show cluster-wide infrastructure security assessments for cluster resources (e.g. nodes). Unlike [Namespace Infrastructure Assessments](namespace-infrastructure-assessments), the scope is the whole cluster. You can open each report to see failed checks, descriptions, and remediation steps. Reports are generated by **Trivy**. + +## Cluster Infrastructure Assessment Reports + +The page title is **Cluster Infrastructure Assessment Reports**, with a short description: *Cluster-wide infrastructure security assessments for cluster resources*. + +### Table + +Use the **Columns** control above the table to choose which columns are visible. The table includes: + +| Column | Description | +|-----------------|-------------| +| **Name** | Name of the assessed cluster resource (e.g. a node such as `node-…compute.internal`). | +| **Critical** | Number of critical findings. | +| **High** | Number of high-severity findings. | +| **Medium** | Number of medium-severity findings. | +| **Low** | Number of low-severity findings. | +| **Total Checks**| Total number of checks run. | +| **Last Updated**| Date and time of the last assessment (may be empty). | + +Each row has an **eye icon** (or similar) at the end to open **Assessment Details**. **Pagination** at the bottom (e.g. "Rows per page: 25", "1–11 of 11") and navigation arrows let you move through the list. + +## Assessment Details + +When you open an assessment from the list, the breadcrumbs show **Security > Cluster Security > Cluster Infrastructure Assessments > Assessment Details**. + +### Header + +* **Resource** — The assessed cluster resource (e.g. a node identified as `…compute.internal` or similar) with a **Cluster** scope indicator. +* **Scan summary** — **Scope: Cluster**, **Checks** (total), **Passed**, **Failed** (e.g. "Checks: 4 Passed: 0 Failed: 4"), **Scanner** and version (e.g. Trivy v0.29.0). +* **Severity counts** — Badges for Critical, High, Medium, Low (e.g. "0 Critical", "4 High"). + +### Security Checks Table + +Above the table you can filter by **Severity** (e.g. "All severities") and **Status** (e.g. "All"). The **Columns** button (e.g. "Columns 5") customizes visible columns. + +The table lists each finding with: + +| Column | Description | +|-------------|-------------| +| **Check ID** | Identifier of the check (e.g. KCV0069, KCV0073, KCV0086, KCV0077). Rows can be expanded to show full details. | +| **Title** | Short title (e.g. "Ensure that the kubelet service file permissions are set to 600 or more restrictive", "Ensure that the -kubeconfig kubelet.conf file permissions are set to 600 or more restrictive"). | +| **Category** | Category of the check (e.g. "Kubernetes Security Check"). | +| **Severity** | Severity level (e.g. High), often with color. | +| **Status** | Result (e.g. Fail), often with an icon. | + +**Expand a row** to see: + +* **Description** — Why the check matters (e.g. the kubelet service file should have restrictive permissions). +* **Messages** — Concrete instance (e.g. which file or setting is involved). +* **Remediation** — What to change, including specific paths where applicable (e.g. set permissions of `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` to 600 or more restrictive, or adjust kubelet config file permissions). + +Use this view to understand each finding and apply the suggested remediation on the cluster nodes. **Pagination** at the bottom (e.g. "1–4 of 4", "Rows per page: 25") applies when there are many findings. + +## Related Articles + +* [Namespace Infrastructure Assessments](./namespace-infrastructure-assessments.md) +* [Cluster Configuration Audits](./cluster-configuration-audits.md) +* [Cluster RBAC Assessments](./cluster-rbac-assessments.md) +* [Cluster Vulnerability Reports](./cluster-vulnerability-reports.md) diff --git a/docs/user-guide/security/cluster-rbac-assessments.md b/docs/user-guide/security/cluster-rbac-assessments.md new file mode 100644 index 0000000000..9f69dd283e --- /dev/null +++ b/docs/user-guide/security/cluster-rbac-assessments.md @@ -0,0 +1,72 @@ +--- +title: "Cluster RBAC Assessments" +sidebar_label: "RBAC Assessments" +description: "Cluster-wide RBAC policy security assessments for ClusterRoles." +--- + + +# Cluster RBAC Assessments + + + + + +**Cluster RBAC Assessment Reports** under **Security > Cluster Security > RBAC Assessments** show cluster-wide RBAC policy security assessments for **ClusterRoles**. Unlike [Namespace RBAC Assessments](namespace-rbac-assessments), the scope is the whole cluster and the assessed resources are ClusterRoles, not namespace-scoped Roles. You can open each report to see failed checks, descriptions, and remediation steps. + +## Cluster RBAC Assessment Reports + +The page title is **Cluster RBAC Assessment Reports**, with a short description: *Cluster-wide RBAC policy security assessments for ClusterRoles*. + +### Table + +Use the **Columns** control (e.g. "Columns 7") above the table to choose which columns are visible. The table includes: + +| Column | Description | +|-----------------|-------------| +| **Name** | Name of the ClusterRole being assessed (e.g. `clusterrole-575df9df4d`). | +| **Critical** | Number of critical findings. | +| **High** | Number of high-severity findings. | +| **Medium** | Number of medium-severity findings. | +| **Low** | Number of low-severity findings. | +| **Total Checks**| Total number of checks run. | + +Each row has an **eye icon** (or similar) at the end to open **Assessment Details**. **Pagination** at the bottom (e.g. "Rows per page: 25") and navigation arrows let you move through the list. + +## Assessment Details + +When you open an assessment from the list, the breadcrumbs show **Security > Cluster Security > Cluster RBAC Assessments > Assessment Details**. + +### Header + +* **Resource** — Name and kind (e.g. `clusterrole-575df9df4d`, **ClusterRole**) with a shield icon in a highlighted block. +* **Scan summary** — **Scope: Cluster**, **Checks** (total), **Passed**, **Failed** (e.g. "Checks: 1 Passed: 0 Failed: 1"), **Scanner** and version (e.g. Trivy v0.29.0). +* **Severity counts** — Badges for Critical, High, Medium, Low (e.g. "1 Critical", "0 High"). + +### Security Checks Table + +Above the table you can filter by **Severity** (e.g. "All severities") and **Status** (e.g. "All"). The **Columns** button (e.g. "Columns 5") customizes visible columns. + +The table lists each finding with: + +| Column | Description | +|-------------|-------------| +| **Check ID** | Identifier of the check (e.g. KSV114). Rows can be expanded to show full details. | +| **Title** | Short title (e.g. "Manage webhookconfigurations"). | +| **Category** | Category of the check (e.g. "Kubernetes Security Check"). | +| **Severity** | Severity level (e.g. Critical), often with color. | +| **Status** | Result (e.g. Fail), often with an icon. | + +**Expand a row** to see: + +* **Description** — Why the check matters (e.g. webhooks can intercept or mutate resources, including secrets and pod specs). +* **Messages** — Concrete instance (e.g. which ClusterRole has which verbs on which resources, such as `mutatingwebhookconfigurations` and `validatingwebhookconfigurations`). +* **Remediation** — What to change (e.g. remove write/impersonate verbs for webhook configuration resources; acceptable verbs may be get, list, watch). + +Use this view to understand each finding and apply the suggested remediation. **Pagination** at the bottom (e.g. "1–1 of 1", "Rows per page: 25") applies when there are many findings. + +## Related Articles + +* [Namespace RBAC Assessments](./namespace-rbac-assessments.md) +* [Cluster Configuration Audits](./cluster-configuration-audits.md) +* [Cluster Infrastructure Assessments](./cluster-infrastructure-assessments.md) +* [Cluster Vulnerability Reports](./cluster-vulnerability-reports.md) diff --git a/docs/user-guide/security/cluster-vulnerability-reports.md b/docs/user-guide/security/cluster-vulnerability-reports.md new file mode 100644 index 0000000000..da2a4e4080 --- /dev/null +++ b/docs/user-guide/security/cluster-vulnerability-reports.md @@ -0,0 +1,81 @@ +--- +title: "Cluster Vulnerability Reports" +sidebar_label: "Vulnerability Reports" +description: "Cluster-wide container image vulnerability reports and scan results." +--- + + +# Cluster Vulnerability Reports + + + + + +**Cluster Vulnerability Reports** under **Security > Cluster Security > Vulnerability Reports** list cluster-wide container image vulnerability reports. Unlike [Container Vulnerability Reports](container-vulnerability-reports) (namespace-scoped), the scope is the whole cluster. You can open each report to see scan metadata and the full list of CVEs. + +## Reports List + +The page title is **Cluster Vulnerability Reports**, with a short description: *Cluster-wide container image vulnerability reports*. There is no namespace filter — the list covers all reported images at cluster level. + +### Table + +Use the **Columns** control (e.g. "Columns 9") to choose which columns are visible. The table includes: + +| Column | Description | +|-------------|-------------| +| **Image** | Container image identifier (e.g. `kubernetes.1.34.2-eks-b312614`). | +| **Critical** | Count of critical vulnerabilities. | +| **High** | Count of high-severity vulnerabilities. | +| **Medium** | Count of medium-severity. | +| **Low** | Count of low-severity. | +| **Unknown** | Count of unknown-severity. | +| **OS Family**| Operating system family of the image (e.g. `amazon`). | +| **Last Updated** | Date and time when the report was last updated. | + +Each row has an **eye icon** (or similar) at the end to open **Report Details**. **Pagination** at the bottom (e.g. "Rows per page: 25", "1–1 of 1") lets you move through the list. + +## Report Details + +When you open a report, the breadcrumbs show **Security > Cluster Security > Cluster Vulnerability Reports > Report Details**. + +At the top you see: + +* **Image identifier** — Full image reference (e.g. `k8s.io/kubernetes:1.34.2-eks-b3126f4`) with a shield icon. A **No Vulnerabilities** badge appears when no issues were found. +* **Context** — **Container** name (e.g. k8s-cluster), **Resource** (e.g. ClusterSbomReport/55967dc54c), **Scope: Cluster**, and base **OS** (e.g. amazon 2023.8.20250908). +* **Severity summary** — Badges with counts: Critical, High, Medium, Low, Unknown (e.g. "0 Critical", "0 High"). + +Two tabs are available: **Overview** and **Vulnerabilities** (with the total count when there are findings). + +### Overview Tab + +The Overview tab shows structured information: + +* **Scan Information** — **Scanner** (e.g. Trivy), **Scanner Version** (e.g. 0.66.0), **Vendor** (e.g. Aqua Security), **Last Scan** (date and time). +* **Image Information** — **Registry** (e.g. k8s.io), **Repository** (e.g. kubernetes), **Tag** (e.g. 1.34.2-eks-b3126f4), **Digest** (if present). +* **Operating System** — **Family** and **Version** of the base image (e.g. amazon 2023.8.20250908). +* **Resource Information** — **Scope** (Cluster), **Resource Kind** (e.g. ClusterSbomReport), **Resource Name**, **Container** name. + +Use this to understand how and when the image was scanned and which cluster resource it belongs to. + +### Vulnerabilities Tab + +The **Vulnerabilities** tab lists all findings for this image. The table has: + +| Column | Description | +|---------------------|-------------| +| **CVE ID** | CVE identifier (e.g. CVE-2026-0861). **Each CVE ID is a link** that opens the vulnerability details in the [Aqua Vulnerability Database](https://avd.aquasec.com/) (e.g. `https://avd.aquasec.com/nvd/2026/cve-2026-0861/`), where you can read description, CVSS, affected software, and mitigations. | +| **Severity** | Severity level (e.g. High), often with a colored tag. | +| **Resource** | Affected package or component. | +| **Installed Version** | Version currently in the image. | +| **Fixed Version** | Version that fixes the issue (may be empty if no fix is known). | +| **Score** | Severity score (e.g. 8.1). | +| **Title** | Short description of the vulnerability. | + +Use **Columns** (e.g. "Columns 7") to customize the table. **Pagination** (e.g. "Rows per page: 25") lets you move through the list when there are many vulnerabilities. If the image has no known vulnerabilities, the tab shows an empty state: **No vulnerabilities found** and a short message such as *This container image has no known vulnerabilities*, with "0 of 0" in the pagination. + +## Related Articles + +* [Container Vulnerability Reports](./container-vulnerability-reports.md) +* [Cluster Configuration Audits](./cluster-configuration-audits.md) +* [Cluster RBAC Assessments](./cluster-rbac-assessments.md) +* [Cluster Infrastructure Assessments](./cluster-infrastructure-assessments.md) diff --git a/docs/user-guide/security/compliance-configuration-audits.md b/docs/user-guide/security/compliance-configuration-audits.md new file mode 100644 index 0000000000..b3afa553d1 --- /dev/null +++ b/docs/user-guide/security/compliance-configuration-audits.md @@ -0,0 +1,20 @@ +--- +title: "Compliance Configuration Audits" +sidebar_label: "Configuration Audits" +description: "Configuration audits in the Compliance section." +--- + + +# Compliance Configuration Audits + + + + + +Under **Security > Compliance > Configuration Audits** you can view configuration audits in the context of compliance. + +## Related Articles + +* [Compliance RBAC Assessments](./compliance-rbac-assessments.md) +* [Compliance Infrastructure Assessments](./compliance-infrastructure-assessments.md) +* [Compliance Vulnerability Reports](./compliance-vulnerability-reports.md) diff --git a/docs/user-guide/security/compliance-infrastructure-assessments.md b/docs/user-guide/security/compliance-infrastructure-assessments.md new file mode 100644 index 0000000000..64ea1c555a --- /dev/null +++ b/docs/user-guide/security/compliance-infrastructure-assessments.md @@ -0,0 +1,20 @@ +--- +title: "Compliance Infrastructure Assessments" +sidebar_label: "Infrastructure Assessments" +description: "Infrastructure assessments in the Compliance section." +--- + + +# Compliance Infrastructure Assessments + + + + + +Under **Security > Compliance > Infrastructure Assessments** you can view infrastructure assessments in the context of compliance. + +## Related Articles + +* [Compliance Configuration Audits](./compliance-configuration-audits.md) +* [Compliance RBAC Assessments](./compliance-rbac-assessments.md) +* [Compliance Vulnerability Reports](./compliance-vulnerability-reports.md) diff --git a/docs/user-guide/security/compliance-rbac-assessments.md b/docs/user-guide/security/compliance-rbac-assessments.md new file mode 100644 index 0000000000..540fce35e0 --- /dev/null +++ b/docs/user-guide/security/compliance-rbac-assessments.md @@ -0,0 +1,20 @@ +--- +title: "Compliance RBAC Assessments" +sidebar_label: "RBAC Assessments" +description: "RBAC assessments in the Compliance section." +--- + + +# Compliance RBAC Assessments + + + + + +Under **Security > Compliance > RBAC Assessments** you can view RBAC assessments in the context of compliance. + +## Related Articles + +* [Compliance Configuration Audits](./compliance-configuration-audits.md) +* [Compliance Infrastructure Assessments](./compliance-infrastructure-assessments.md) +* [Compliance Vulnerability Reports](./compliance-vulnerability-reports.md) diff --git a/docs/user-guide/security/compliance-vulnerability-reports.md b/docs/user-guide/security/compliance-vulnerability-reports.md new file mode 100644 index 0000000000..d8fa118f88 --- /dev/null +++ b/docs/user-guide/security/compliance-vulnerability-reports.md @@ -0,0 +1,20 @@ +--- +title: "Compliance Vulnerability Reports" +sidebar_label: "Vulnerability Reports" +description: "Vulnerability reports in the Compliance section." +--- + + +# Compliance Vulnerability Reports + + + + + +Under **Security > Compliance > Vulnerability Reports** you can view vulnerability reports in the context of compliance. + +## Related Articles + +* [Compliance Configuration Audits](./compliance-configuration-audits.md) +* [Compliance RBAC Assessments](./compliance-rbac-assessments.md) +* [Compliance Infrastructure Assessments](./compliance-infrastructure-assessments.md) diff --git a/docs/user-guide/security/container-exposed-secrets.md b/docs/user-guide/security/container-exposed-secrets.md new file mode 100644 index 0000000000..2e0b0aa1e8 --- /dev/null +++ b/docs/user-guide/security/container-exposed-secrets.md @@ -0,0 +1,19 @@ +--- +title: "Exposed Secrets" +sidebar_label: "Exposed Secrets" +description: "Detection and listing of exposed secrets in container scanning." +--- + + +# Exposed Secrets + + + + + +Under **Security > Container Scanning > Exposed Secrets** you can see secrets that were detected in container images or configurations and need to be remediated. + +## Related Articles + +* [Container Scanning Overview](./container-scanning-overview.md) +* [Container Vulnerability Reports](./container-vulnerability-reports.md) diff --git a/docs/user-guide/security/container-scanning-overview.md b/docs/user-guide/security/container-scanning-overview.md new file mode 100644 index 0000000000..59cec8ccff --- /dev/null +++ b/docs/user-guide/security/container-scanning-overview.md @@ -0,0 +1,64 @@ +--- +title: "Container Scanning Overview" +sidebar_label: "Overview" +description: "Trivy security overview — container image vulnerabilities and severity breakdown." +--- + + +# Container Scanning Overview + + + + + +The **Container Scanning > Overview** page shows the **Trivy Security Overview** dashboard: a summary of container image vulnerabilities for the selected namespace (and cluster) in the portal header. + +## Key metrics + +At the top, four cards summarize the current state: + +* **Total Vulnerabilities** — Total number of vulnerabilities across all scanned images. +* **Critical Vulnerabilities** — Count of critical issues (with a note that they require immediate attention). +* **Images Scanned** — Number of container images scanned. +* **Fixable Vulnerabilities** — How many vulnerabilities have a fix available (with a note "Fix available"). + +Use these to quickly see exposure and remediation potential. + +## Severity Breakdown + +A table lists vulnerability distribution by severity: + +| Severity | Count | Fixable | Distribution | +|-----------|-------|---------|--------------| +| Critical | … | … | …% (bar) | +| High | … | … | …% (bar) | +| Medium | … | … | …% (bar) | +| Low | … | … | …% (bar) | +| Unknown | … | … | …% (bar) | +| **Total** | … | … | 100% (bar) | + +Each row shows the count, how many are fixable, and a horizontal bar for the share of that severity in the total. + +## Severity Distribution + +A **donut chart** shows the same breakdown by severity (e.g. Critical, High, Medium, Low, Unknown) with labels and percentages, so you can see at a glance where most issues sit. + +## Top Vulnerable Images + +A table lists images with the highest vulnerability counts. For each image you typically see: + +* Image name (e.g. `library/nginx:latest`). +* Namespace (e.g. the current namespace). +* Counts by severity: Critical, High, Medium, Low. +* Total vulnerability count. + +Use this to prioritize which images to update or replace. + +## Vulnerability Reports + +At the bottom of the page, a **Vulnerability Reports** block is shown: *View all container vulnerability scan results*, with an arrow. **Clicking this block opens the [Vulnerability Reports](container-vulnerability-reports) section**, where you can see the full list of container vulnerability scan results and drill into details. + +## Related Articles + +* [Container Vulnerability Reports](./container-vulnerability-reports.md) +* [Exposed Secrets](./container-exposed-secrets.md) diff --git a/docs/user-guide/security/container-vulnerability-reports.md b/docs/user-guide/security/container-vulnerability-reports.md new file mode 100644 index 0000000000..220e095dce --- /dev/null +++ b/docs/user-guide/security/container-vulnerability-reports.md @@ -0,0 +1,79 @@ +--- +title: "Container Vulnerability Reports" +sidebar_label: "Vulnerability Reports" +description: "Unique container images with vulnerabilities and detailed scan results." +--- + + +# Container Vulnerability Reports + + + + + +**Container Vulnerability Reports** lists unique container images that have vulnerabilities in the selected namespace. You can open each report to see scan metadata and the full list of CVEs. This page is reachable from **Security > Container Scanning > Vulnerability Reports** or by clicking the **Vulnerability Reports** block on the [Container Scanning Overview](container-scanning-overview) page. + +## Reports List + +The page shows a short description such as *Unique container images with vulnerabilities in namespace <namespace>*. At the top right you can change the **Namespace** to filter by namespace. + +### Table + +Use the **Columns** control (e.g. "Columns 9") to choose which columns are visible. The table includes: + +| Column | Description | +|-------------|-------------| +| **Image** | Container image (e.g. `library/nginx:latest`). Rows can be expanded (arrow) for more detail. | +| **Namespace** | Namespace where the image is used. | +| **Resources** | Number of resources using this image (e.g. "1 resource"); the value is clickable and leads to the report details. | +| **Critical** | Count of critical vulnerabilities. | +| **High** | Count of high-severity vulnerabilities. | +| **Medium** | Count of medium-severity. | +| **Low** | Count of low-severity. | +| **Total** | Total vulnerability count. | +| **Last Scan**| Date and time of the last scan. | + +**Pagination** at the bottom (e.g. "Rows per page 25", "1–1 of 1") lets you move through the list. Click a row or the **Resources** link to open **Report Details** for that image. + +## Report Details + +When you open a report, the breadcrumbs show **Security > Container Scanning > Vulnerability Reports > Report Details**. + +At the top you see: + +* **Severity summary** — Badges with counts: Critical, High, Medium, Low, Unknown (e.g. "0 Critical", "5 High"). +* **Container block** — Image name (e.g. `index.docker.io/library/nginx:latest`), **Container** name, **Resource** (e.g. ReplicaSet/webserver-bc6dbb848), **Namespace**, and base **OS** (e.g. debian 13.3). + +Two tabs are available: **Overview** and **Vulnerabilities** (with the total count, e.g. "Vulnerabilities 5"). + +### Overview Tab + +The Overview tab shows structured information: + +* **Scan Information** — **Scanner** (e.g. Trivy), **Scanner Version** (e.g. 0.66.0), **Vendor** (e.g. Aqua Security), **Last Scan** (date and time). +* **Image Information** — **Registry** (e.g. index.docker.io), **Repository** (e.g. library/nginx), **Tag** (e.g. latest), **Digest** (truncated hash). +* **Operating System** — **Family** and **Version** of the base image (e.g. debian 13.3). +* **Resource Information** — **Namespace**, **Resource Kind** (e.g. ReplicaSet), **Resource Name**, **Container** name. + +Use this to understand how and when the image was scanned and where it runs. + +### Vulnerabilities Tab + +The **Vulnerabilities** tab lists all findings for this image. The table has: + +| Column | Description | +|---------------------|-------------| +| **CVE ID** | CVE identifier (e.g. CVE-2026-0861, CVE-2026-22695). **Each CVE ID is a link** that opens the vulnerability details in the [Aqua Vulnerability Database](https://avd.aquasec.com/) (e.g. `https://avd.aquasec.com/nvd/2026/cve-2026-0861/`), where you can read description, CVSS, affected software, and mitigations. | +| **Severity** | Severity level (e.g. High), often with a colored tag. | +| **Resource** | Affected package or component. | +| **Installed Version** | Version currently in the image. | +| **Fixed Version** | Version that fixes the issue (may be empty if no fix is known). | +| **Score** | Severity score (e.g. 8.1, 7.1). | +| **Title** | Short description of the vulnerability. | + +Use **Columns** (e.g. "Columns 7") to customize the table. **Pagination** (e.g. "Rows per page: 25", "1–5 of 5") lets you move through the list when there are many vulnerabilities. + +## Related Articles + +* [Container Scanning Overview](./container-scanning-overview.md) +* [Exposed Secrets](./container-exposed-secrets.md) diff --git a/docs/user-guide/security/namespace-configuration-audits.md b/docs/user-guide/security/namespace-configuration-audits.md new file mode 100644 index 0000000000..f810276d9f --- /dev/null +++ b/docs/user-guide/security/namespace-configuration-audits.md @@ -0,0 +1,72 @@ +--- +title: "Namespace Configuration Audits" +sidebar_label: "Configuration Audits" +description: "Kubernetes resource misconfigurations in the namespace — audit reports and findings." +--- + + +# Namespace Configuration Audits + + + + + +**Configuration Audit Reports** under **Security > Namespace Security > Configuration Audits** show Kubernetes resource misconfigurations in the selected namespace. You can open each resource to see failed checks, descriptions, and remediation steps. + +## Configuration Audit Reports + +The page title is **Configuration Audit Reports**, with a short description such as *Kubernetes resource misconfigurations in namespace <namespace>*. In the top right you can change the **Namespace** to filter reports. + +### Table + +Use the **Columns** control above the table to choose which columns are visible. The table includes: + +| Column | Description | +|------------------|-------------| +| **Resource Name** | Name of the Kubernetes resource (e.g. ReplicaSet name). | +| **Resource Kind** | Kind of resource (e.g. ReplicaSet). | +| **Critical** | Number of critical findings. | +| **High** | Number of high-severity findings. | +| **Medium** | Number of medium-severity findings. | +| **Low** | Number of low-severity findings. | +| **Total Checks** | Total number of checks run. | +| **Last Updated** | Date and time of the last audit. | + +Each row has an **eye icon** (or similar) at the end to open **Audit Details**. **Pagination** at the bottom (e.g. "Rows per page: 25", "1–1 of 1") and navigation arrows let you move through the list. + +## Audit Details + +When you open a resource, the breadcrumbs show **Security > Namespace Security > Configuration Audits > Audit Details**. + +### Header + +* **Resource** — Name and kind (e.g. `webserver-bc6dbb848`, ReplicaSet) in a highlighted block. +* **Scan summary** — **Namespace**, **Checks** (total), **Passed**, **Failed** (e.g. "Checks: 3 Passed: 0 Failed: 3"), **Scanner** and version (e.g. Trivy v0.29.0), **Last scan** (date and time). +* **Severity counts** — Badges for Critical, High, Medium, Low (e.g. "0 Critical", "3 High"). + +### Audit Findings Table + +Above the table you can filter by **Severity** (e.g. "All severities") and **Status** (e.g. "All"). The **Columns** button customizes visible columns. + +The table lists each finding with: + +| Column | Description | +|-------------|-------------| +| **Check ID** | Identifier of the check (e.g. KSV014, KSV118). Rows can be expanded to show full details. | +| **Title** | Short title (e.g. "Root file system is not read-only", "Default security context configured"). | +| **Category** | Category of the check (e.g. "Kubernetes Security Check"). | +| **Severity** | Severity level (e.g. High), often with color. | +| **Status** | Result (e.g. Fail), often with an icon. | + +**Expand a row** to see: + +* **Description** — Why the check matters (e.g. an immutable root filesystem limits what attackers can write to disk). +* **Messages** — Concrete instance of the issue (e.g. which container and resource should be changed). +* **Remediation** — What to change to fix it (e.g. set `containers[].securityContext.readOnlyRootFilesystem` to `true`). + +Use this view to understand each finding and apply the suggested remediation. **Pagination** at the bottom (e.g. "1–3 of 3", "Rows per page: 25") applies when there are many findings. + +## Related Articles + +* [Namespace RBAC Assessments](./namespace-rbac-assessments.md) +* [Namespace Infrastructure Assessments](./namespace-infrastructure-assessments.md) diff --git a/docs/user-guide/security/namespace-infrastructure-assessments.md b/docs/user-guide/security/namespace-infrastructure-assessments.md new file mode 100644 index 0000000000..e457386a91 --- /dev/null +++ b/docs/user-guide/security/namespace-infrastructure-assessments.md @@ -0,0 +1,21 @@ +--- +title: "Namespace Infrastructure Assessments" +sidebar_label: "Infrastructure Assessments" +description: "Infrastructure security assessments in the namespace via Trivy." +--- + + +# Namespace Infrastructure Assessments + + + + + +**Infrastructure Assessment Reports** under **Security > Namespace Security > Infrastructure Assessments** show infrastructure security assessments for resources in the selected namespace. Reports are generated by **Trivy**. + +**Trivy** is an open-source security scanner that can assess infrastructure (e.g. Kubernetes manifests, Terraform, and other IaC). In this view, Trivy runs infrastructure checks; once resources in the namespace are scanned, assessment reports appear in the table. The table lists resources with columns such as Resource Name, Resource Kind, counts by severity (Critical, High, Medium, Low), Total Checks, and Last Updated. If no scans have run yet, the page shows a message that no infrastructure assessment reports were found and that Trivy reports will appear once resources are scanned. + +## Related Articles + +* [Namespace Configuration Audits](./namespace-configuration-audits.md) +* [Namespace RBAC Assessments](./namespace-rbac-assessments.md) diff --git a/docs/user-guide/security/namespace-rbac-assessments.md b/docs/user-guide/security/namespace-rbac-assessments.md new file mode 100644 index 0000000000..1c2f209415 --- /dev/null +++ b/docs/user-guide/security/namespace-rbac-assessments.md @@ -0,0 +1,71 @@ +--- +title: "Namespace RBAC Assessments" +sidebar_label: "RBAC Assessments" +description: "RBAC policy security assessments in the namespace — roles and findings." +--- + + +# Namespace RBAC Assessments + + + + + +**RBAC Assessment Reports** under **Security > Namespace Security > RBAC Assessments** show RBAC policy security assessments in the selected namespace. You can open each resource (e.g. Role) to see failed checks, descriptions, and remediation steps. + +## RBAC Assessment Reports + +The page title is **RBAC Assessment Reports**, with a short description such as *RBAC policy security assessments in namespace <namespace>*. In the top right you can change the **Namespace** to filter reports. + +### Table + +Use the **Columns** control above the table to choose which columns are visible. The table includes: + +| Column | Description | +|------------------|-------------| +| **Resource Name** | Name of the RBAC resource (e.g. Role or RoleBinding name such as `crossplane-admin`, `crossplane-edit`). | +| **Resource Kind** | Kind of resource (e.g. **Role**). | +| **Critical** | Number of critical findings. | +| **High** | Number of high-severity findings. | +| **Medium** | Number of medium-severity findings. | +| **Low** | Number of low-severity findings. | +| **Total Checks** | Total number of checks run. | + +Each row has an **eye icon** (or similar) at the end to open **Assessment Details**. **Pagination** at the bottom (e.g. "Rows per page: 25", "1–3 of 3") and navigation arrows let you move through the list. + +## Assessment Details + +When you open an assessment from the list, the breadcrumbs show **Security > Namespace Security > RBAC Assessments > Assessment Details**. + +### Header + +* **Resource** — Name and kind (e.g. `crossplane-admin`, **Role**) with a shield icon in a highlighted block. +* **Scan summary** — **Namespace**, **Checks** (total), **Passed**, **Failed** (e.g. "Checks: 2 Passed: 0 Failed: 2"), **Scanner** and version (e.g. Trivy v0.29.0). +* **Severity counts** — Badges for Critical, High, Medium, Low (e.g. "2 Critical", "0 High"). + +### Security Checks Table + +Above the table you can filter by **Severity** (e.g. "All severities") and **Status** (e.g. "All"). The **Columns** button customizes visible columns. + +The table lists each finding with: + +| Column | Description | +|-------------|-------------| +| **Check ID** | Identifier of the check (e.g. KSV050, KSV045). Rows can be expanded to show full details. | +| **Title** | Short title (e.g. "Manage Kubernetes RBAC resources", "No wildcard verb roles"). | +| **Category** | Category of the check (e.g. "Kubernetes Security Check"). | +| **Severity** | Severity level (e.g. Critical), often with color. | +| **Status** | Result (e.g. Fail), often with an icon. | + +**Expand a row** to see: + +* **Description** — Why the check matters (e.g. an effective level of access equivalent to cluster-admin should not be provided). +* **Messages** — Concrete instance (e.g. which Role has which verbs on which resources, such as `roles` and `rolebindings`). +* **Remediation** — What to change (e.g. remove write permission verbs for `roles` and `rolebindings`, or avoid wildcard verbs). + +Use this view to understand each RBAC finding and apply the suggested remediation. **Pagination** at the bottom (e.g. "1–2 of 2", "Rows per page: 25") applies when there are many findings. + +## Related Articles + +* [Namespace Configuration Audits](./namespace-configuration-audits.md) +* [Namespace Infrastructure Assessments](./namespace-infrastructure-assessments.md) diff --git a/docs/user-guide/security/sca-overview.md b/docs/user-guide/security/sca-overview.md new file mode 100644 index 0000000000..2794cd3d67 --- /dev/null +++ b/docs/user-guide/security/sca-overview.md @@ -0,0 +1,69 @@ +--- +title: "SCA Overview" +sidebar_label: "Overview" +description: "Portfolio-level Software Composition Analysis metrics and policy violations." +--- + + +# SCA Overview + + + + + +The Security section covers security settings, access control, secrets management, and protected resources. It is organized into the following sub-sections: + +* **SCA** (Software Composition Analysis) — [Overview](./sca-overview), [Projects](./sca-projects) +* **SAST** — [SAST](./sca-sast) +* **Container Scanning** — [Overview](./container-scanning-overview), [Vulnerability Reports](./container-vulnerability-reports), [Exposed Secrets](./container-exposed-secrets) +* **Namespace Security** — [Configuration Audits](./namespace-configuration-audits), [RBAC Assessments](./namespace-rbac-assessments), [Infrastructure Assessments](./namespace-infrastructure-assessments) +* **Cluster Security** — [Compliance](./cluster-compliance), [Configuration Audits](./cluster-configuration-audits), [RBAC Assessments](./cluster-rbac-assessments), [Infrastructure Assessments](./cluster-infrastructure-assessments), [Vulnerability Reports](./cluster-vulnerability-reports) +* **Compliance** — [Configuration Audits](./compliance-configuration-audits), [RBAC Assessments](./compliance-rbac-assessments), [Infrastructure Assessments](./compliance-infrastructure-assessments), [Vulnerability Reports](./compliance-vulnerability-reports) + +The **Software Composition Analysis** portfolio dashboard (this page) shows portfolio-level vulnerability metrics and policy violations across all projects. Use it to track vulnerabilities, projects at risk, and policy compliance over time. + +## Key Metrics + +Four KPI cards with trend lines summarize: + +* **Portfolio Vulnerabilities** — Total vulnerability count for the portfolio. +* **Projects at Risk** — Number of projects that have active risk (e.g. vulnerabilities or policy violations). +* **Vulnerable Components** — Number of components (dependencies) with known vulnerabilities. +* **Inherited Risk Score** — Aggregate risk score derived from vulnerabilities and policy state. + +At the top of the page you can select **30 Days**, **60 Days**, **90 Days**, or **1 Year** to scope all metrics and charts. + +## Portfolio Statistics + +A summary block shows current counts: + +* **Projects** and **Vulnerable Projects** +* **Components** and **Vulnerable Components** +* **Policy Violations** — total, plus split by **License**, **Operational**, and **Security** +* **Portfolio Vulnerabilities** and **Suppressed** (suppressed findings) + +Use this to see the overall posture at a glance. + +## Charts + +* **Portfolio Vulnerabilities** — Stacked area chart of vulnerabilities over time by severity: Critical, High, Medium, Low, Unassigned. Legend shows current counts and percentages. + +* **Policy Violations by State** — Stacked area chart of violations by state: Fail, Warn, Info. + +* **Policy Violations by Classification** — Stacked area chart by type: Security, License, Operational. + +* **Auditing Progress (Findings)** — Trend of **Audited** vs **Unaudited** findings over the selected period. + +* **Auditing Progress (Violations)** — Trend of **Audited** vs **Unaudited** violations. + +* **Projects** — Stacked area chart of **Non-Vulnerable** vs **Vulnerable** projects over time (with total project count). + +* **Components** — Stacked area chart of **Non-Vulnerable** vs **Vulnerable** components over time (with total component count). + +Charts use the same time range as the page filter and show a last-measurement timestamp. + +## Related Articles + +* [SCA Projects](./sca-projects.md) +* [Observability](../observability.md) +* [KubeRocketCI Widgets](../widgets.md) diff --git a/docs/user-guide/security/sca-projects.md b/docs/user-guide/security/sca-projects.md new file mode 100644 index 0000000000..348808fff0 --- /dev/null +++ b/docs/user-guide/security/sca-projects.md @@ -0,0 +1,58 @@ +--- +title: "SCA Projects" +sidebar_label: "Projects" +description: "Software composition analysis projects and their security metrics." +--- + + +# SCA Projects + + + + + +The **SCA Projects** view lists software composition analysis projects and their security metrics. Use it to find projects by name or version and see risk scores, vulnerability counts, and policy violations at a glance. + +## Projects Table + +A search bar at the top lets you **search projects by name or version**. The table shows one row per project (or per project version) with these columns: + +* **Project Name** — Name of the project (e.g. codebase or application). +* **Version** — Version or branch (e.g. `master`, `main`, `1.0.0`). +* **Latest** — Indicates whether this version is the latest. +* **Classifier** — Type of project: `APPLICATION`, `LIBRARY`, or other. +* **Last BOM Import** — Date and time of the last Bill of Materials (BOM) import. +* **BOM Format** — Format of the BOM (e.g. `CycloneDX 1.6`). +* **Risk Score** — Numerical risk score for the project. +* **Active** — Whether the project is active (e.g. `Active`). +* **Vulnerabilities** — Count of vulnerabilities; often shown with a horizontal bar (e.g. green when zero). +* **Policy Violations** — Count of policy violations; same visual style as vulnerabilities. + +You can change which columns are visible using the **Columns** control (e.g. "Columns 10") and use pagination at the bottom (rows per page, e.g. 25; navigation for pages). + +## Project Details + +When you click a project row, you open **Project Details** for that project. The breadcrumbs show **Security > SCA > Projects > Project Details**. + +At the top you see the project name (e.g. `edp-codebase-operator`), a branch/version dropdown (e.g. `master`), and a **View in Dependency Track** link. A summary row shows vulnerability counts by criticality: **Critical**, **High**, **Medium**, **Low**, **Unassigned** (each with a count). + +Tabs let you switch between: + +* **Overview** — Vulnerability trend graph, summary cards (Critical, High, Medium, Low, Unassigned, Risk Score), and policy violations by state and by classification. +* **Components** — List of components (dependencies) with counts. +* **Services** — Services associated with the project. +* **Dependency Graph** — Graph view of dependencies. +* **Audit Vulnerabilities** — Vulnerabilities pending or audited. +* **Exploit Predictions** — Predicted exploits. +* **Policy Violations** — Policy violations with breakdown by criticality. + +### Overview Tab + +* **Project Vulnerabilities** — Metadata (Last BOM Import, Last Vulnerability Analysis, Last Measurement), a **vulnerability trend** line chart over time by severity, and **summary cards** for Critical, High, Medium, Low, Unassigned, and Risk Score. +* **Policy Violations by State** — Chart or list of violations by state (e.g. Fail, Warn, Info). +* **Policy Violations by Classification** — Breakdown by classification (e.g. Security Risk, License Risk, Operational Risk) with counts and percentages. + +## Related Articles + +* [SCA Overview](./sca-overview.md) +* [Security](../security.md) diff --git a/docs/user-guide/security/sca-sast.md b/docs/user-guide/security/sca-sast.md new file mode 100644 index 0000000000..df959812db --- /dev/null +++ b/docs/user-guide/security/sca-sast.md @@ -0,0 +1,94 @@ +--- +title: "SAST" +sidebar_label: "SAST" +description: "Static Application Security Testing — SonarQube projects and their code quality metrics." +--- + + +# SAST + + + + + +**Static Application Security Testing (SAST)** in KubeRocketCI shows SonarQube projects and their code quality metrics. Use **Security > SAST > Projects** to see all projects and open details for any of them. + +## SAST Projects + +The **SAST > Projects** page lists projects analyzed by SonarQube. The subtitle describes it as *SonarQube projects and their code quality metrics*. + +### Search and Table + +* **Search** — Use **Search projects by name...** at the top to filter the list. +* **Columns** — The **Columns** control (e.g. "Columns 9") lets you choose which columns are shown. + +The table includes: + +| Column | Description | +|--------|-------------| +| **Project Name** | Name of the codebase or application. | +| **Quality Gate** | Status: **Passed** (green checkmark) or **N/A** (gray). | +| **Visibility** | Project visibility (e.g. **PUBLIC**). | +| **Bugs** | Number of bugs (e.g. `0 A`; the letter is a grade). | +| **Vulnerabilities** | Number of vulnerabilities (e.g. `0 A`). | +| **Code Smells** | Number of code smells (e.g. `2 A`, `1 A`). | +| **Coverage** | Test coverage percentage (e.g. `0.0%`, `77.8%`). | +| **Duplications** | Duplicated lines percentage (e.g. `0.0%`). | +| **Last Analysis** | Date and time of the last analysis. | + +Use this view to monitor security and code quality across projects at a glance. + +## Project Details + +When you click a project in the list, you open **Project Details**. The breadcrumbs show **Security > SAST > Projects > Project Details**. + +At the top you see: + +* **Project name** (e.g. `example-sast-project`) and a **PUBLIC** badge. +* **Key** — SonarQube project key (e.g. `Key: example-sast-project`). +* **Last analysis** — Timestamp of the last run. +* **View in SonarQube** — Link to open the project in SonarQube. + +A **metrics bar** shows summary grades and values: **Vulnerabilities**, **Bugs**, **Code Smells**, **Hotspots Reviewed**, **Coverage**, **Duplications** (with letter grades like A and color indicators). + +Two main tabs are available: **Overview** and **Issues**. + +### Overview Tab + +The Overview tab shows card-based metrics: + +* **Reliability** — Number of bugs (with grade badge, e.g. A). +* **Security** — Number of vulnerabilities (with grade badge). +* **Maintainability** — Code smells and technical debt (with grade badge). +* **Security Review** — Security hotspots to review (with grade badge). +* **Coverage** — Test coverage percentage (with color dot, e.g. red for 0%). +* **Duplications** — Duplicated lines density (with color dot). +* **Size** — Lines of code. +* **Quality Gate** — Quality gate status (e.g. **Passed** with OK badge). + +**Quality Gate Details** is a table with columns: **Metric**, **Operator**, **Threshold**, **Actual**, **Status**. It lists each quality gate condition (e.g. `blocker_violations`, `critical_violations`) and whether the project meets it (OK or not). You can change visible columns via the **Columns** control (e.g. "Columns 5"). + +### Issues Tab + +The **Issues** tab shows findings for the project (e.g. "Issues 2" when there are 2 issues). + +* **Issue type filters** — **All Issues**, **Bugs**, **Vulnerabilities**, **Code Smells** to filter by kind. +* **Severity filters** — Buttons for **BLOCKER**, **CRITICAL**, **MAJOR**, **MINOR**, **INFO** to filter by severity. + +The issues table has: + +| Column | Description | +|--------|-------------| +| **Severity** | Severity with icon (e.g. **MAJOR**). | +| **Type** | Issue type (e.g. **CODE_SMELL**). | +| **Message** | Short description of the issue. | +| **File** | File path and line (e.g. `src/app/app.component.css:1`); often clickable. | +| **Effort** | Estimated fix effort (e.g. "1 min", "5 mins"). | +| **Created** | When the issue was created or last seen (e.g. analysis date). | + +Use **Columns** to customize the table. **Pagination** at the bottom (e.g. "Rows per page: 25", "1–2 of 2") lets you move through the list when there are many issues. + +## Related Articles + +* [SCA Overview](./sca-overview.md) +* [SCA Projects](./sca-projects.md) diff --git a/docs/user-guide/tekton-pipelines.md b/docs/user-guide/tekton-pipelines.md index 118c1c2294..4c538146db 100644 --- a/docs/user-guide/tekton-pipelines.md +++ b/docs/user-guide/tekton-pipelines.md @@ -97,13 +97,7 @@ The TriggerTemplate defines parameters (e.g., service account name, timeout) and ### Security Pipeline -Security pipeline conducts security scans and vulnerability assessments as a standalone process, decoupled from the build pipelines. Moving security checks into a separate pipeline enables more frequent, targeted scans, reduces build pipeline time, and allows to manage and evolve scanning logic independently of application delivery. - - ![Security pipeline](../assets/user-guide/tekton-pipelines/security-pipeline.png "Security pipeline") - -The scan result summary can be found in the **Results** tab. It refers you to the DefectDojo tool: - - ![Security pipeline results](../assets/user-guide/tekton-pipelines/security-pipeline-results.png "Security pipeline results") +Security pipeline conducts security scans and vulnerability assessments as a standalone process, decoupled from the build pipelines. Moving security checks into a separate pipeline enables more frequent, targeted scans, reduces build pipeline time, and allows to manage and evolve scanning logic independently of application delivery. The scan result summary can be found in the **Results** tab. It refers you to the DefectDojo tool. ### Test Pipeline @@ -111,8 +105,6 @@ Test pipelines execute automated tests for environments independently of deploym Previously, autotests could only be triggered after the application deploy pipeline, but with test pipelines, tests are now fully independent of deployment. This separation allows teams to validate application functionality on demand, run tests at any stage, and improve feedback cycles by decoupling testing from application delivery. - ![Test pipeline](../assets/user-guide/tekton-pipelines/test-pipelines.png "Test pipeline") - ### Release Pipelines Release pipeline orchestrates the approval and publishing workflow for new releases, supporting organizational compliance and governance requirements. By isolating release logic in its own pipeline, teams can implement custom approval steps, integrate with external systems, and ensure that release processes are auditable and consistent. @@ -121,8 +113,6 @@ Release pipeline orchestrates the approval and publishing workflow for new relea KubeRocketCI does not offer pre-built release pipelines. You can create custom release pipelines tailored to your project's needs. ::: - ![Release pipeline](../assets/user-guide/tekton-pipelines/release-pipeline.png "Release pipeline") - ## Trigger Pipelines A specific event triggers each pipeline type. @@ -135,9 +125,7 @@ Trigger a review pipeline using one of the four methods: ![Pull request in Bitbucket](../assets/user-guide/tekton-pipelines/bitbucket-pull-request.png "Pull request in Bitbucket") -2. Use the **Run Again** button on the PipelineRun details page in the KubeRocketCI portal (if a PipelineRun exists): - - ![Rerun review pipeline](../assets/user-guide/tekton-pipelines/review-pipeline-run-again.png "Rerun review pipeline") +2. Use the **Run Again** button on the PipelineRun details page in the KubeRocketCI portal (if a PipelineRun exists). 3. Use the **Rerun** button on the PipelineRun details page in the Tekton dashboard (if a PipelineRun exists): @@ -157,25 +145,19 @@ Overall, there are four methods of triggering a build pipeline: 1. Merge a pull request into a configured branch. -2. Use the **Run Again** button in the KubeRocketCI portal (if a PipelineRun exists): +2. Use the **Run Again** button in the KubeRocketCI portal (if a PipelineRun exists). - ![Rerun build pipeline](../assets/user-guide/tekton-pipelines/build-pipeline-run-again.png "Rerun build pipeline") - -3. Use the Rerun button in the Tekton dashboard (if a PipelineRun exists): +3. Use the **Rerun** button in the Tekton dashboard (if a PipelineRun exists): ![Rerun build pipeline in Tekton](../assets/user-guide/tekton-pipelines/build-pipeline-tekton-dashboard-rerun.png "Rerun build pipeline in Tekton") -4. Use the Trigger Build PipelineRun button in the KubeRocketCI portal within the branches section: - - ![Manually trigger build pipeline](../assets/user-guide/tekton-pipelines/trigger-build-pipeline-run.png "Manually trigger build pipeline") +4. Use the **Build** button in the KubeRocketCI portal within the branches section. ### Deploy Pipeline Deploy pipelines can be triggered manually or automatically. Automatic triggers are implemented using the **TriggerType** custom resource. There are three ways to trigger a deploy pipeline: -1. Use **Configure Deploy** and **Start Deploy** buttons in the KubeRocketCI portal: - - ![Delete branch](../assets/user-guide/tekton-pipelines/deploy-pipeline-configure-deploy.png "Delete branch") +1. Use **Configure Deploy** and **Start Deploy** buttons in the KubeRocketCI portal. 2. Configure the pipeline with the `Auto` TriggerType to deploy automatically after the build pipeline finishes and a new artifact version is created. @@ -193,13 +175,9 @@ To trigger a security, test, and release pipeline, follow the steps below: 2. Open the **Pipelines** tab. -3. On the **Pipelines** tab, use the filter to select a security, test, or release pipeline: - - ![Pipeline filters](../assets/user-guide/tekton-pipelines/pipeline-filters.png "Pipeline filters") - -4. In the pipelines list, click the actions button and select **Run with parameters**: +3. On the **Pipelines** tab, use the filter to select a security, test, or release pipeline. - ![Run with parameters](../assets/user-guide/tekton-pipelines/run-with-parameters.png "Run with parameters") +4. In the pipelines list, click the actions button and select **Run with parameters**. 5. On the create resource window, specify the required parameters and click **Save & Apply**: @@ -212,7 +190,15 @@ To trigger a security, test, and release pipeline, follow the steps below: - ![Specify parameters](../assets/user-guide/tekton-pipelines/specify-parameters.png "Specify parameters") + ```bash + params: + - name: git-source-url + value: git@github.com:/orders-processing.git + - name: git-source-revision + value: main + - name: CODEBASE_NAME + value: orders-processing + ``` * **git-source-url**: Git or HTTPS address of the Git repository where the application code is stored. * **git-source-revision**: Git branch of the repository. @@ -220,7 +206,17 @@ To trigger a security, test, and release pipeline, follow the steps below: - ![Specify parameters](../assets/user-guide/tekton-pipelines/specify-parameters-test.png "Specify parameters") + ```bash + params: + - name: git-source-url + value: git@github.com:/orders-processing.git + - name: git-source-revision + value: main + - name: makefile-target + value: dev + - name: base-image + value: epamedp/maven-java21-make:0.1.3 + ``` * **git-source-url**: Git or HTTPS address of the Git repository where the autotests are stored. * **git-source-revision**: Git branch of the repository. diff --git a/docs/user-guide/widgets.md b/docs/user-guide/widgets.md index 53a162c3be..fcc1183716 100644 --- a/docs/user-guide/widgets.md +++ b/docs/user-guide/widgets.md @@ -16,48 +16,49 @@ This page describes all the widgets presented in KubeRocketCI. ## Widgets Overview -The first widgets users view when using KubeRocketCI portal are KubeRocketCI resource widgets: +The first widget users view when using KubeRocketCI portal is **Platform Dashboard**. It shows the amount of pipeline runs, amount of failed pipeline runs and percentage of successful pipeline runs. When clicking on this small widget, you will be redirected to the Overview page which will show you the following widget groups: - ![Overview page](../assets/user-guide/widgets/resource-widgets.png "Overview page") +* **Header**: Shows you the total amount of PipelineRuns, their success rate, failed pipelines, and average duration. -These widgets reflect all the resources in the **default namespace**: +* **Pipeline Activity (7 days)**: Shows you 7 columns that represent the amount of triggered pipeline runs and their success rate. -* **Codebases**: Displays all the created codebases; -* **Branches**: Shows the total amount of codebase branches; -* **Pipelines**: Shows all the initiated pipeline runs; -* **Deployment Flows**: Displays all the created deployment flows; -* **Environments**: Shows the total amount of created environments; -* **+ Add Widget**: Opens the **Add new widget** window. +* **Resource Health**: these widgets reflect all the resources in the **default namespace**: + * **Codebases**: Displays all the created codebases; + * **Branches**: Shows the total amount of codebase branches; + * **Pipelines**: Shows all the initiated pipeline runs; + * **Deployments**: Displays all the created deployments; + * **Environments**: Shows the total amount of created environments; + * **+ Add Widget**: Opens the **Add new widget** window. -The status of the resources is displayed real-time and doesn't require any preliminary configuration to for widgets to work. Not only these widgets display the amount of resources but also their statuses (success, fail, in progress). +* **Resource Usage**: These widgets show you a summary of cluster resources consumed by the platform. -Additionally, users can track any specific application status and deployed versions using custom widgets. To add a custom widget, follow the steps below: +* **Vulnerability Summary**: This is the total amount of vulnerabilities of the Projects found by Dependency-Track. -1. On the **Overview** section, click the **+ Add Widget** button: +* **SonarQube Quality**: This is the summary for all the SonarQube Projects. - ![Add widget button](../assets/user-guide/widgets/add-widget.png "Add widget button") +* **Recent Pipeline Activity**: Shows recent PipelineRuns, including their name (clickable), status, duration, and start time. -2. On the **Add new widget** window, select the **Application deployed versions** widget type: +* **DORA Metrics**: These widgets provide insights into software delivery performance using DORA metrics, including Deployment Frequency and Change Failure Rate, covering the past 30 days. - ![Select widget type](../assets/user-guide/widgets/select-widget-type.png "Select widget type") +* **Links**: Clickable links that can lead you to other services integrated with the platform. You can manually create Quick Links by following the instructions in the [Manage Quick Links](./quick-links.md) guide. + +The status of the resources is displayed real-time and doesn't require any preliminary configuration to for widgets to work. Not only these widgets display the amount of resources but also their statuses (success, fail, in progress). -3. Select the application to track and click **Add**: +Additionally, users can track any specific application status and deployed versions using custom widgets. To add a custom widget, follow the steps below: - ![Select application to track](../assets/user-guide/widgets/select-application-to-track.png "Select application to track") +1. On the **Overview** section, click the **+ Add Widget** button. -4. View the application widget to get the information about Deployment Flows and Environments where application is deployed: +2. On the **Add new widget** window, select the **Application deployed versions** widget type. - ![View widget details](../assets/user-guide/widgets/application-track-widget.png "View widget details") +3. Select the application to track and click **Add**. -5. To delete the widget, hover your mouse cursor over the widget block and click the bin icon that appears: +4. View the application widget to get the information about Deployments and Environments where application is deployed. - ![Delete widget](../assets/user-guide/widgets/delete-widget.png "Delete widget") +5. To delete the widget, hover your mouse cursor over the widget block and click the bin icon that appears. ## SonarQube & Dependency-Track Widgets -KubeRocketCI also offers widgets to track codebases' code quality directly from the KubeRocketCI portal. These widgets pull codebase-related data from SonarQube and Dependency-Track tools: - - ![Overview page](../assets/user-guide/widgets/empty-sq-dt-widgets.png "Overview page") +KubeRocketCI also offers widgets to track codebases' code quality directly from the KubeRocketCI portal. These widgets pull codebase-related data from SonarQube and Dependency-Track tools. To enable these widgets, you need to pass the following steps: @@ -69,9 +70,7 @@ To enable these widgets, you need to pass the following steps: At least one build pipeline must be run for the codebase to activate the widgets. ::: -4. Verify the widgets started working for the codebase: - - ![SonarQube and Dependency-Track widgets](../assets/user-guide/widgets/active-sq-dt-widgets.png "SonarQube and Dependency-Track widgets") +4. Verify the widgets started working for the codebase. :::note The SonarQube and Dependency-Track widgets only track the default branch. @@ -79,11 +78,9 @@ The SonarQube and Dependency-Track widgets only track the default branch. ## Resource Quota Widget -The last available widget is a resource quota widget. To open the widget, click the circle icon in the top-left corner of the screen: - - ![Overview page](../assets/user-guide/widgets/resource-quota-widget.png "Overview page") +The last available widget is a resource quota widget. To open the widget, click the circle icon in the top-right corner of the screen. -This widget shows resource requests and limits (CPU, Memory, Namespace) of both the deployment flows and the entire platform. +This widget shows resource requests and limits (CPU, Memory, Namespace) of both the deployments and the entire platform. To enable the widget, you need to deploy KubeRocketCI in a [Capsule](../operator-guide/advanced-installation/capsule.md) tenant. diff --git a/sidebars.ts b/sidebars.ts index 14d9ce55ee..c8c6e94437 100644 --- a/sidebars.ts +++ b/sidebars.ts @@ -401,10 +401,11 @@ const sidebars: SidebarsConfig = { collapsible: false, items: [ 'user-guide/index', + 'user-guide/overview', 'user-guide/portal-settings', { type: 'category', - label: 'Pipelines', + label: 'CI/CD Pipelines', collapsed: false, items: [ 'user-guide/pipelines', @@ -413,16 +414,7 @@ const sidebars: SidebarsConfig = { }, { type: 'category', - label: 'Marketplace', - collapsed: false, - items: [ - 'user-guide/marketplace', - 'user-guide/add-marketplace', - ], - }, - { - type: 'category', - label: 'Components', + label: 'Projects', collapsed: false, items: [ 'user-guide/components', @@ -466,7 +458,7 @@ const sidebars: SidebarsConfig = { }, { type: 'category', - label: 'Deployment Flows', + label: 'Deployments', collapsed: false, items: [ 'user-guide/add-cd-pipeline', @@ -478,6 +470,62 @@ const sidebars: SidebarsConfig = { 'user-guide/argo-cd-preview', ], }, + 'user-guide/observability', + { + type: 'category', + label: 'Security', + collapsed: false, + items: [ + { + type: 'category', + label: 'SCA', + items: [ + 'user-guide/security/sca-overview', + 'user-guide/security/sca-projects', + ], + }, + 'user-guide/security/sca-sast', + { + type: 'category', + label: 'Container Scanning', + items: [ + 'user-guide/security/container-scanning-overview', + 'user-guide/security/container-vulnerability-reports', + 'user-guide/security/container-exposed-secrets', + ], + }, + { + type: 'category', + label: 'Namespace Security', + items: [ + 'user-guide/security/namespace-configuration-audits', + 'user-guide/security/namespace-rbac-assessments', + 'user-guide/security/namespace-infrastructure-assessments', + ], + }, + { + type: 'category', + label: 'Cluster Security', + items: [ + 'user-guide/security/cluster-compliance', + 'user-guide/security/cluster-configuration-audits', + 'user-guide/security/cluster-rbac-assessments', + 'user-guide/security/cluster-infrastructure-assessments', + 'user-guide/security/cluster-vulnerability-reports', + ], + }, + { + type: 'category', + label: 'Compliance', + items: [ + 'user-guide/security/compliance-configuration-audits', + 'user-guide/security/compliance-rbac-assessments', + 'user-guide/security/compliance-infrastructure-assessments', + 'user-guide/security/compliance-vulnerability-reports', + ], + }, + ], + }, { type: 'category', label: 'Configuration', @@ -516,13 +564,6 @@ const sidebars: SidebarsConfig = { 'user-guide/change-container-registry', ], }, - { - type: 'category', - label: 'Gen AI', - items: [ - 'user-guide/add-ai-assistant', - ], - }, ], }, 'user-guide/widgets', diff --git a/src/features/user-guide/components/UserGuideCards/index.tsx b/src/features/user-guide/components/UserGuideCards/index.tsx new file mode 100644 index 0000000000..3a9de79953 --- /dev/null +++ b/src/features/user-guide/components/UserGuideCards/index.tsx @@ -0,0 +1,33 @@ +import Heading from '@theme/Heading'; +import styles from './styles.module.css'; +import { userGuideList } from '../../constants'; +import clsx from 'clsx'; +import Link from '@docusaurus/Link'; +import { useActiveVersion } from '@docusaurus/plugin-content-docs/client'; + +export const UserGuideCards = () => { + const version = useActiveVersion('default'); + const versionPath = version?.path ?? 'next'; + + return ( +
+
+
+ {userGuideList.map(({ docPath, title, description, icon }, idx) => ( +
+ +
+ + + {title} + +
+
{description}
+ +
+ ))} +
+
+
+ ); +}; diff --git a/src/features/user-guide/components/UserGuideCards/styles.module.css b/src/features/user-guide/components/UserGuideCards/styles.module.css new file mode 100644 index 0000000000..ce6b0683e8 --- /dev/null +++ b/src/features/user-guide/components/UserGuideCards/styles.module.css @@ -0,0 +1,53 @@ +.sectionWrapper { + padding: 1.5rem 0; +} + +.gridItem { + padding: 0.75rem; +} + +.root { + display: flex; + flex-direction: column; + height: 100%; + padding: 1.5rem; + border-radius: 4px; + color: var(--ifm-color-emphasis); + box-shadow: 0px 1px 10px 0px rgba(0, 36, 70, 0.12); + border: 1px solid transparent; + background-color: var(--kuberocket-card-color); +} + +.root:hover { + text-decoration: none; + color: var(--ifm-color-emphasis); + border: 1px solid var(--kuberocket-color-primary-light, rgba(33, 150, 243, 1)); + background-color: var(--kuberocket-card-color-hover); +} + +.title { + margin: 0; + font-size: 1.25rem; + font-weight: 500; +} + +.header { + display: flex; + gap: 0.5rem; + align-items: center; + margin-bottom: 1rem; +} + +.description { + font-size: 0.75rem; +} + +.icon { + height: 1.5rem; + width: 1.5rem; +} + +/* In dark theme, invert black icons so they become light and visible */ +:global([data-theme='dark']) .icon { + filter: invert(1); +} diff --git a/src/features/user-guide/constants.tsx b/src/features/user-guide/constants.tsx new file mode 100644 index 0000000000..a9a3861c69 --- /dev/null +++ b/src/features/user-guide/constants.tsx @@ -0,0 +1,79 @@ +import { UserGuideItem } from './types'; + +export const userGuideList: UserGuideItem[] = [ + { + title: 'Overview', + icon: '/img/panels-top-left.svg', + description: ( + <> + The main dashboard of the KubeRocketCI portal: widgets, quick links, and navigation to the main platform + sections. + + ), + docPath: 'user-guide/overview', + }, + { + title: 'CI/CD Pipelines', + icon: '/img/activity.svg', + description: ( + <> + Manage build, review, and deployment pipelines. View pipeline runs, history, and pipeline details in one + place. + + ), + docPath: 'user-guide/pipelines', + }, + { + title: 'Projects', + icon: '/img/box.svg', + description: ( + <> + Applications, libraries, autotests, and infrastructures. Create and manage codebases and their + onboarding strategies. + + ), + docPath: 'user-guide/components', + }, + { + title: 'Deployments', + icon: '/img/cloud-upload.svg', + description: ( + <> + Deployment flows, environments, and GitOps. Configure how applications are promoted and deployed to + target environments. + + ), + docPath: 'user-guide/add-cd-pipeline', + }, + { + title: 'Observability', + icon: '/img/bot.svg', + description: ( + <> + Monitoring, logging, and visibility into pipeline runs, application statuses, and platform metrics. + + ), + docPath: 'user-guide/observability', + }, + { + title: 'Security', + icon: '/img/shield.svg', + description: ( + <> + Security settings, access control, secrets management, and protected resources in the platform. + + ), + docPath: 'user-guide/security', + }, + { + title: 'Configuration', + icon: '/img/settings.svg', + description: ( + <> + Integrations and features: container registries, Git servers, clusters, quick links, and other + platform settings. + + ), + docPath: 'user-guide/configuration-overview', + }, +]; diff --git a/src/features/user-guide/types.ts b/src/features/user-guide/types.ts new file mode 100644 index 0000000000..d9bcf29ab3 --- /dev/null +++ b/src/features/user-guide/types.ts @@ -0,0 +1,9 @@ +import React from 'react'; + +export interface UserGuideItem { + title: string; + icon: string; + description: React.JSX.Element; + /** Doc path relative to docs root (e.g. "user-guide/overview"). Link is built with current version in the component. */ + docPath: string; +} diff --git a/static/img/activity.svg b/static/img/activity.svg new file mode 100644 index 0000000000..d3dc09a8a1 --- /dev/null +++ b/static/img/activity.svg @@ -0,0 +1,3 @@ + diff --git a/static/img/bot.svg b/static/img/bot.svg new file mode 100644 index 0000000000..469392a560 --- /dev/null +++ b/static/img/bot.svg @@ -0,0 +1,8 @@ + diff --git a/static/img/box.svg b/static/img/box.svg new file mode 100644 index 0000000000..fab489843c --- /dev/null +++ b/static/img/box.svg @@ -0,0 +1,5 @@ + diff --git a/static/img/cloud-upload.svg b/static/img/cloud-upload.svg new file mode 100644 index 0000000000..5856c8c157 --- /dev/null +++ b/static/img/cloud-upload.svg @@ -0,0 +1,5 @@ + diff --git a/static/img/panels-top-left.svg b/static/img/panels-top-left.svg new file mode 100644 index 0000000000..2852b9af99 --- /dev/null +++ b/static/img/panels-top-left.svg @@ -0,0 +1,5 @@ + \ No newline at end of file diff --git a/static/img/settings.svg b/static/img/settings.svg new file mode 100644 index 0000000000..3140324f29 --- /dev/null +++ b/static/img/settings.svg @@ -0,0 +1,4 @@ + diff --git a/static/img/shield.svg b/static/img/shield.svg new file mode 100644 index 0000000000..23a68a13b6 --- /dev/null +++ b/static/img/shield.svg @@ -0,0 +1,3 @@ + diff --git a/versioned_sidebars/version-3.10-sidebars.json b/versioned_sidebars/version-3.10-sidebars.json index eb57ab3d7c..23ec885f43 100644 --- a/versioned_sidebars/version-3.10-sidebars.json +++ b/versioned_sidebars/version-3.10-sidebars.json @@ -482,13 +482,6 @@ "user-guide/manage-container-registries", "user-guide/change-container-registry" ] - }, - { - "type": "category", - "label": "Gen AI", - "items": [ - "user-guide/add-ai-assistant" - ] } ] }, diff --git a/versioned_sidebars/version-3.11-sidebars.json b/versioned_sidebars/version-3.11-sidebars.json index f2ef227f7c..29f6773a60 100644 --- a/versioned_sidebars/version-3.11-sidebars.json +++ b/versioned_sidebars/version-3.11-sidebars.json @@ -487,13 +487,6 @@ "user-guide/manage-container-registries", "user-guide/change-container-registry" ] - }, - { - "type": "category", - "label": "Gen AI", - "items": [ - "user-guide/add-ai-assistant" - ] } ] }, diff --git a/versioned_sidebars/version-3.12-sidebars.json b/versioned_sidebars/version-3.12-sidebars.json index 5726789ed2..0dc3b83792 100644 --- a/versioned_sidebars/version-3.12-sidebars.json +++ b/versioned_sidebars/version-3.12-sidebars.json @@ -489,13 +489,6 @@ "user-guide/manage-container-registries", "user-guide/change-container-registry" ] - }, - { - "type": "category", - "label": "Gen AI", - "items": [ - "user-guide/add-ai-assistant" - ] } ] },