weaveworks · opudrovs · Nov 22, 2023 · Nov 22, 2023
diff --git a/.github/workflows/acceptance-test.yaml b/.github/workflows/acceptance-test.yaml
@@ -74,7 +74,7 @@ on:
         description: "Cluster user admin password hash"
         required: true
       WGE_DEX_CLIENT_SECRET:
-        description: "client credential secret for managment cluster OIDC (dex)"
+        description: "client credential secret for management cluster OIDC (dex)"
         required: true
       WGE_DEX_CLI_CLIENT_SECRET:
         description: "client credential secret for CLI OIDC (dex)"

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -366,7 +366,7 @@ $ ./tools/create-leaf-cluster.sh leaf-cluster-01
 
 This command will create a new cluster and configure the `GitopsCluster` CR pointing to the cluster's kubeconfig.
 
-Note that this won't configure completelly the cluster, you might need to install flux and rbac rules in order to be able to query it properly. But it should be already visible on the Weave Gitops cluster's tab.
+Note that this won't configure completelly the cluster, you might need to install flux and rbac rules in order to be able to query it properly. But it should be already visible on the Weave GitOps cluster's tab.
 
 ### How to install everything from your working branch on a cluster
 
@@ -581,7 +581,7 @@ make core-ui && make core-lib
 ```bash
 export WG_VERSION=0.2.4
 
-# 1.update the backend golang code
+# 1. Update the backend Golang code
 go get -d github.com/weaveworks/weave-gitops@$WG_VERSION
 go mod tidy
 

diff --git a/api/gitauth/gitauth.proto b/api/gitauth/gitauth.proto
@@ -1,6 +1,6 @@
 /**
  * This file holds the protobuf definitions
- * for the Weave Gitops Enterprise Git Provider Authentication API.
+ * for the Weave GitOps Enterprise Git Provider Authentication API.
  */
 syntax = "proto3";
 
@@ -13,10 +13,10 @@ option go_package = "github.com/weaveworks/weave-gitops-enterprise/gitauth/api";
 
 option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
     info: {
-      title: "Weave Gitops Enterprise GitAuth API",
+      title: "Weave GitOps Enterprise GitAuth API",
       version: "0.1";
       description:
-          "Weave Gitops Enterprise GitAuth API handles authentication"
+          "Weave GitOps Enterprise GitAuth API handles authentication"
           " via Github and Gitlab";
     };
     consumes: "gitauth/json";

diff --git a/api/gitauth/gitauth.swagger.json b/api/gitauth/gitauth.swagger.json
diff --git a/cmd/clusters-service/api/cluster_services.proto b/cmd/clusters-service/api/cluster_services.proto
@@ -164,15 +164,15 @@ service ClustersService {
     };
   }
 
-  // Get the Weave Gitops Enterprise version
+  // Get the Weave GitOps Enterprise version
   rpc GetEnterpriseVersion(GetEnterpriseVersionRequest) returns (GetEnterpriseVersionResponse) {
     option (google.api.http) = {
       // Namespaced under /enterprise/ so as not to conflict with the OSS endpoint
       get : "/v1/enterprise/version"
     };
   }
 
-  // Get the Weave Gitops Enterprise configuration
+  // Get the Weave GitOps Enterprise configuration
   rpc GetConfig(GetConfigRequest) returns (GetConfigResponse) {
     option (google.api.http) = {
       get : "/v1/config"

diff --git a/cmd/clusters-service/api/cluster_services.swagger.json b/cmd/clusters-service/api/cluster_services.swagger.json
diff --git a/cmd/clusters-service/pkg/protos/cluster_services_grpc.pb.go b/cmd/clusters-service/pkg/protos/cluster_services_grpc.pb.go
diff --git a/cmd/gitops/app/bootstrap/cmd.go b/cmd/gitops/app/bootstrap/cmd.go
@@ -17,7 +17,7 @@ const (
 	cmdLongDescription  = `Installs Weave GitOps Enterprise in simple steps:
 - Entitlements: check that you have valid entitlements.
 - Flux: check or bootstrap Flux. 
-- Weave Gitops: check or install a supported Weave GitOps version with default configuration.
+- Weave GitOps: check or install a supported Weave GitOps version with default configuration.
 - Authentication: check or setup cluster user authentication to access the dashboard.
 `
 	cmdExamples = `

diff --git a/docs/architecture/README.md b/docs/architecture/README.md
@@ -25,12 +25,12 @@ Diagrams aim to be self-explanatory however:
 
 ## Getting Started
 
-It depends on your expected outcome. This section assumes that you are an engineering within Weave Gitops and you are onboarding
+It depends on your expected outcome. This section assumes that you are an engineering within Weave GitOps and you are onboarding
 to the product within a particular business domain. We suggest you use this documentation as part of the onboarding to get started:
 
-1. Head to [Weave Gitops System](#system) as it provides you a high-level understanding on who are the users and Weave Gitops Dependencies.
-2. Review [Weave Gitops Tiers](#tiers) as it provides with the layering of the application and access to the codebase by tier.
-3. View the [Weave Gitops Domain](#domains) to provide you a high level overview of the problem spaces that Weave Gitops faces.
+1. Head to [Weave GitOps System](#system) as it provides you a high-level understanding on who are the users and Weave GitOps Dependencies.
+2. Review [Weave GitOps Tiers](#tiers) as it provides with the layering of the application and access to the codebase by tier.
+3. View the [Weave GitOps Domain](#domains) to provide you a high level overview of the problem spaces that Weave GitOps faces.
 4. Select the domain that you would be contributing to. Understand the solution space via
    - its diagram and user flows,
    - follow the tiers approach UI -> API -> Backend,
@@ -120,19 +120,19 @@ More info about each of them could be found within their domain. See [domains vi
 
 ### Scalability, High Availability and Disaster Recovery 
 
-#### Weave Gitops Enterprise Management Console
+#### Weave GitOps Enterprise Management Console
 
-In terms of scalability Weave Gitops Enterprise Management Console presents the following features:
+In terms of scalability Weave GitOps Enterprise Management Console presents the following features:
 
-- It uses golang's HTTP infrastructure which handles concurrent connections efficiently, so API server instances scale well vertically
+- It uses Golang's HTTP infrastructure which handles concurrent connections efficiently, so API server instances scale well vertically
 - In terms of scalability models, Weave GitOps Enterprise management app could scale vertically to simplify operations, or 
 it could also do it horizontally as:
   - User sessions are self-contained in cookies that comes in each user request.
   - We don't hold application state, but we serve it from Kubernetes. 
   - Our data layer is cache layer with read-only capabilities that lives alongside each of the server instances.
 - High Availability can be achieved by having multiple API server instanced behind a load balancer with sticky sessions enabled.
 - Disaster Recovery for the app, as the state is hold in Kubernetes, follows the same approach as any other stateless application and
-  to be determined by the DR strategy of the team running the platform running Weave Gitops Enterprise.
+  to be determined by the DR strategy of the team running the platform running Weave GitOps Enterprise.
 
 #### Kubernetes Controllers
 
@@ -143,7 +143,7 @@ About the Kubernetes controllers the following statements are true:
 - These controllers are built in Go following Kubernetes industry-standard approach based on [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder)
   and [controller runtime,](https://github.com/kubernetes-sigs/controller-runtime) so they could achieve HA via multiple instances with enabled [leader-election](https://pkg.go.dev/github.com/kubernetes-sigs/controller-runtime/pkg/leaderelection). 
 - Disaster Recovery for controllers, as the state is hold in kubernetes, follows the same approach as any other stateless application and 
-to be determined by the DR strategy of the team running the platform running Weave Gitops Enterprise.
+to be determined by the DR strategy of the team running the platform running Weave GitOps Enterprise.
 
 ## Weave GitOps Enterprise
 
@@ -179,17 +179,17 @@ WGE sits on top or integrate a set of external systems for gitops delivery and r
 
 The following diagram represents the system as a whole. The following considerations might be useful to be fully 
 understand the diagram:
-- Weave Gitops Cluster is represented once for simplicity but in reality is presented as:   
-  - Weave Gitops Management Cluster: single instance that holds the management console and control plane controllers.
-  - Weave Gitops Leaf Cluster: multiple instances that run business applications and managed by Weave Gitops Management Cluster.
+- Weave GitOps Cluster is represented once for simplicity but in reality is presented as:   
+  - Weave GitOps Management Cluster: single instance that holds the management console and control plane controllers.
+  - Weave GitOps Leaf Cluster: multiple instances that run business applications and managed by Weave GitOps Management Cluster.
 
 - In terms of **data-flows**, the line starts by the source entity starting the connection and commonly starting a request. For example, 
-Weave Gitops Enterprise opens connections to a Git Provider api for example to request creating a Pull Request.
+Weave GitOps Enterprise opens connections to a Git Provider api for example to request creating a Pull Request.
 - In terms of **networks**, we could say that:
-    - Weave Gitops Cluster:
+    - Weave GitOps Cluster:
       - All components from a cluster lives in the same kubernetes cluster so under the same kubernetes control plane that would be commonly
           deployed in the same network (for example in a VPC). 
-      - Communication between Weave Gitops Management and Weave Gitops Leaf clusters happens via Kubernetes API so needs to be accessible.
+      - Communication between Weave GitOps Management and Weave GitOps Leaf clusters happens via Kubernetes API so needs to be accessible.
       - Platform Engineers or Developers consumes the app via a web browser that would communicate with the API server via either public or private networks depending on the customer deployment.
     - External Systems outside Management or Leaf could communicate via public or private network depending on the customer needs and requirements. 
     For example, it could communicate with GitHub via internet if using the hosted version, or via internal network if using GitHub Enterprise self-hosted.
@@ -222,7 +222,7 @@ C4Context
     UpdateRelStyle(WeaveGitopsEnterprise, Idp, $offsetX="-50", $offsetY="-20")
 
 
-    Boundary(Runtime, "Weave Gitops Cluster") {
+    Boundary(Runtime, "Weave GitOps Cluster") {
         Boundary(Kubernetes, "Kubernetes") {
             System_Ext(KubernetesCluster, "Kubernetes Cluster", "run customer applications")
         }

diff --git a/docs/architecture/application-delivery.md b/docs/architecture/application-delivery.md
@@ -1,5 +1,5 @@
 # Application Delivery 
-This document outlines an architecture documentation for Weave Gitops Application Delivery domain.
+This document outlines an architecture documentation for Weave GitOps Application Delivery domain.
 
 ## Motivation
 As software business, value is delivered to the users or customers by enabling them to do actions.
@@ -26,8 +26,8 @@ Pipelines enables a user to deliver application changes across different environ
 There are three main pipeline journeys:
 
 1. As developer, to add a pipeline for my application, which is a regular gitops flow [Pipeline](https://docs.gitops.weave.works/docs/pipelines/spec/v1alpha1/pipeline/) 
-2. As developer to view my application pipelines via [Weave Gitops UI](https://docs.gitops.weave.works/docs/pipelines/getting-started/)  
-3. As developer to promote my application along the pipeline stages via [Weave Gitops UI](https://docs.gitops.weave.works/docs/pipelines/promoting-applications/) 
+2. As developer to view my application pipelines via [Weave GitOps UI](https://docs.gitops.weave.works/docs/pipelines/getting-started/)  
+3. As developer to promote my application along the pipeline stages via [Weave GitOps UI](https://docs.gitops.weave.works/docs/pipelines/promoting-applications/) 
 
 ```mermaid
 C4Component

diff --git a/docs/architecture/devex.md b/docs/architecture/devex.md
@@ -1,5 +1,5 @@
 # Development Experience 
-This document outlines an architecture documentation for Weave Gitops Development Experience domain
+This document outlines an architecture documentation for Weave GitOps Development Experience domain
 
 ## Motivation
 

diff --git a/docs/architecture/explore.md b/docs/architecture/explore.md
@@ -12,7 +12,7 @@ Explore is the capability that allows searching across multiple infrastructure d
 
 There is a single user journey:
 
-1. As developer, I like to search for resources across my platform using [Weave Gitops UI](https://docs.gitops.weave.works/docs/explorer/getting-started/)  
+1. As developer, I like to search for resources across my platform using [Weave GitOps UI](https://docs.gitops.weave.works/docs/explorer/getting-started/)  
 
 There are two main components:
 

diff --git a/docs/architecture/self-service.md b/docs/architecture/self-service.md
@@ -83,9 +83,9 @@ GitOpsTemplates enable Application Developers to self-service components and ser
 User flows are two:
 1. make a template available which uses a regular gitops flow for [GitopsTemplate](https://docs.gitops.weave.works/docs/gitops-templates/creating-templates/) resource. 
 2. use or update a GitopsTemplate where
-   1. A platform engineering searches and select the temaplate to use via Weave Gitops UI.
-   2. Fills the template and submits the template rendering request to Weave Gitops.
-   3. Authenticates with GitProvider or git provider via Weave Gitops
+   1. A platform engineering searches and select the temaplate to use via Weave GitOps UI.
+   2. Fills the template and submits the template rendering request to Weave GitOps.
+   3. Authenticates with GitProvider or git provider via Weave GitOps
    4. Weave GitOps creates a PR in the provider with the generated resources. 
 
 ```mermaid
@@ -145,8 +145,8 @@ User flows are two:
 1. To make a profile available which uses a regular gitops flow for [Helm Releases](https://docs.gitops.weave.works/docs/cluster-management/profiles/).
 2. Add profiles to your clusters via cluster creation or [adding an application](https://docs.gitops.weave.works/docs/cluster-management/add-applications/):
    1. A platform engineering selects the profiles repository, application, layer and application values.
-   2. Authenticates with GitProvider or git provider via Weave Gitops.
-   3. Weave gitops creates a PR with the profile HelmRelease/HelmRepository.
+   2. Authenticates with GitProvider or git provider via Weave GitOps.
+   3. Weave GitOps creates a PR with the profile HelmRelease/HelmRepository.
    4. Source controller syncs after merge
    5. Helm Controller deploys the helm release 
 

diff --git a/docs/architecture/trusted-delivery.md b/docs/architecture/trusted-delivery.md
@@ -1,5 +1,5 @@
 # Trusted Delivery 
-This document outlines an architecture documentation for Weave Gitops Trusted Delivery domain.
+This document outlines an architecture documentation for Weave GitOps Trusted Delivery domain.
 
 ## Motivation
 
@@ -31,7 +31,7 @@ And the following flows:
 1. A platform engineer via gitops flow, to provision the policy runtime and library via policy profile.
 2. A platform engineer via gitops flow, add custom policies or policy config.
 3. Policy runtime to enforce policies and send policy events to external system like ELK.
-4. Platform engineer to view policy violations via Weave Gitops UI. 
+4. Platform engineer to view policy violations via Weave GitOps UI. 
 
 ```mermaid
 C4Component

diff --git a/docs/cicd.md b/docs/cicd.md
@@ -1,8 +1,8 @@
-# Weave Gitops Enterprise CI/CD
+# Weave GitOps Enterprise CI/CD
 
 This document aims to characterise the Ci/CD pipeline for change until it reaches production.
 In our context, given that we are not SaaS company, our definition of production environment
-is until the change gets released as part of a [Weave Gitops release](https://github.com/weaveworks/weave-gitops-enterprise/releases)
+is until the change gets released as part of a [Weave GitOps release](https://github.com/weaveworks/weave-gitops-enterprise/releases)
 As expected, Flux for deployment and Github Actions as CI.
 
 ## PR Journey 
@@ -23,7 +23,7 @@ The journey of a Weaveworks engineer development is the following:
 deployed to [Staging](https://gitops.internal-dev.wego-gke.weave.works) environment by Flux. This environment helps us to:
     - Functional testing of the feature in a released environment
     - Monitor performance of the capability
-6. The feature will be released according to the week-release cadence that we have for Weave Gitops.
+6. The feature will be released according to the week-release cadence that we have for Weave GitOps.
 
 ## Environments
 
@@ -34,4 +34,4 @@ that we use to recreate the application locally. See [Tiltfile](../Tiltfile).
 - Test/Staging: once code gets into main branch, it gets deployed to [Staging](https://gitops.internal-dev.wego-gke.weave.works) environment where a developer 
 is able to monitor its behaviour in a long-lived environment. 
 - Production: we don't have a production environment as compared to a SaaS company, as our product gets deployed by customers in their environments. However, we have internal 
-customers (ex. Sales) that provide us early-feedback for any new Weave Gitops Enterprise release.  
+customers (ex. Sales) that provide us early-feedback for any new Weave GitOps Enterprise release.  
diff --git a/docs/code-quality.md b/docs/code-quality.md
@@ -1,6 +1,6 @@
 # Code Quality and Security
 
-This doc provides an overview on the actions taken for code quality and security posture for Weave Gitops Enterprise. 
+This doc provides an overview on the actions taken for code quality and security posture for Weave GitOps Enterprise. 
 
 ## Code
 
@@ -51,11 +51,11 @@ We have the following three capabilities identified:
 We use [GitHub Dependabot](https://github.com/dependabot) for vulnerability management. 
 They are actively reviewed and managed via PR associated with the engineering teams. 
 
-![dependandbot security alerts for Weave Gitops Enterprise](resources/dependandbot-security-alerts.png)
+![dependandbot security alerts for Weave GitOps Enterprise](resources/dependandbot-security-alerts.png)
 
 ### License Checking
 
-We use Fossa for doing license checking. An example of it could be seen in [Weave Gitops OSS](https://app.fossa.com/reports/005da7c4-1f10-4889-9432-8b97c2084e41) 
+We use Fossa for doing license checking. An example of it could be seen in [Weave GitOps OSS](https://app.fossa.com/reports/005da7c4-1f10-4889-9432-8b97c2084e41) 
 
 ### Static Code Analysis