Update stakater/.github action to v0.0.117 (0.12)

.github/workflows/closed_pr.yaml

@@ -7,6 +7,6 @@ on:
 
 jobs:
   push:
-    uses: stakater/.github/.github/workflows/[email protected].90
+    uses: stakater/.github/.github/workflows/[email protected].117
     secrets:
-      GH_TOKEN: ${{ secrets.STAKATER_GITHUB_TOKEN }}
+      GH_TOKEN: ${{ secrets.PUBLISH_TOKEN }}

.github/workflows/delete_branch.yaml

@@ -4,6 +4,8 @@ on: delete
 
 jobs:
   delete:
-    uses: stakater/.github/.github/workflows/[email protected]
+    uses: stakater/.github/.github/workflows/[email protected]
+    with:
+      LATEST_DOC_VERSION: "1.1"
     secrets:
-      GH_TOKEN: ${{ secrets.STAKATER_GITHUB_TOKEN }}
+      GH_TOKEN: ${{ secrets.PUBLISH_TOKEN }}

.github/workflows/pull_request.yaml

@@ -3,30 +3,32 @@ name: Pull Request
 on:
   pull_request:
     branches:
-      - "main"
-      - "[0-9]+.[0-9]+"
+      - 'main'
+      - '[0-9]+.[0-9]+'
 
 jobs:
   doc_qa:
-    uses: stakater/.github/.github/workflows/[email protected].90
+    uses: stakater/.github/.github/workflows/[email protected].117
     with:
       MD_CONFIG: .github/md_config.json
       DOC_SRC: content
       MD_LINT_CONFIG: .markdownlint.yaml
+  deploy_doc:
+    uses: stakater/.github/.github/workflows/[email protected]
+    secrets:
+      GH_TOKEN: ${{ secrets.PUBLISH_TOKEN }}
   build_container:
+    needs: deploy_doc
     if: ${{ github.base_ref == 'main' }}
-    uses: stakater/.github/.github/workflows/[email protected].90
+    uses: stakater/.github/.github/workflows/[email protected].117
     with:
       DOCKER_BUILD_CONTEXTS: content=https://github.com/stakater/mto-docs.git#pull-request-deployments
       DOCKER_FILE_PATH: Dockerfile
-    secrets:
       CONTAINER_REGISTRY_URL: ghcr.io/stakater
-      CONTAINER_REGISTRY_USERNAME: stakater-user
-      CONTAINER_REGISTRY_PASSWORD: ${{ secrets.STAKATER_GITHUB_TOKEN }}
+    secrets:
+      CONTAINER_REGISTRY_USERNAME: ${{ github.actor }}
+      CONTAINER_REGISTRY_PASSWORD: ${{ secrets.GHCR_TOKEN }}
       SLACK_WEBHOOK_URL: ${{ secrets.STAKATER_DELIVERY_SLACK_WEBHOOK }}
-      DOCKER_SECRETS: GIT_AUTH_TOKEN=${{ secrets.STAKATER_GITHUB_TOKEN }}
+      DOCKER_SECRETS: GIT_AUTH_TOKEN=${{ secrets.PUBLISH_TOKEN }}
+
 
-  deploy_doc:
-    uses: stakater/.github/.github/workflows/[email protected]
-    secrets:
-      GH_TOKEN: ${{ secrets.STAKATER_GITHUB_TOKEN }}

.github/workflows/push.yaml

@@ -3,11 +3,13 @@ name: Push
 on:
   push:
     branches:
-      - "main"
-      - "[0-9]+.[0-9]+"
+      - 'main'
+      - '[0-9]+.[0-9]+'
 
 jobs:
   push:
-    uses: stakater/.github/.github/workflows/[email protected]
+    uses: stakater/.github/.github/workflows/[email protected]
+    with:
+      LATEST_DOC_VERSION: "1.1"
     secrets:
-      GH_TOKEN: ${{ secrets.STAKATER_GITHUB_TOKEN }}
+      GH_TOKEN: ${{ secrets.PUBLISH_TOKEN }}

.github/workflows/release.yaml

@@ -3,22 +3,22 @@ name: Release
 on:
   push:
     tags:
-      - "v*"
+      - 'v*'
 
 jobs:
   create_release:
-    uses: stakater/.github/.github/workflows/[email protected].90
+    uses: stakater/.github/.github/workflows/[email protected].117
     secrets:
       SLACK_WEBHOOK_URL: ${{ secrets.STAKATER_DELIVERY_SLACK_WEBHOOK }}
   build_container:
-    uses: stakater/.github/.github/workflows/[email protected].90
+    uses: stakater/.github/.github/workflows/[email protected].117
     with:
       DOCKER_BUILD_CONTEXTS: content=https://github.com/stakater/mto-docs.git#gh-pages
       DOCKER_FILE_PATH: Dockerfile
     secrets:
       CONTAINER_REGISTRY_URL: ghcr.io/stakater
-      CONTAINER_REGISTRY_USERNAME: stakater-user
-      CONTAINER_REGISTRY_PASSWORD: ${{ secrets.STAKATER_GITHUB_TOKEN }}
+      CONTAINER_REGISTRY_USERNAME: ${{ github.actor }}
+      CONTAINER_REGISTRY_PASSWORD: ${{ secrets.GHCR_TOKEN }}
       SLACK_WEBHOOK_URL: ${{ secrets.STAKATER_DELIVERY_SLACK_WEBHOOK }}
-      GH_TOKEN: ${{ secrets.STAKATER_GITHUB_TOKEN }}
-      DOCKER_SECRETS: GIT_AUTH_TOKEN=${{ secrets.STAKATER_GITHUB_TOKEN }}
+      GH_TOKEN: ${{ secrets.PUBLISH_TOKEN }}
+      DOCKER_SECRETS: GIT_AUTH_TOKEN=${{ secrets.PUBLISH_TOKEN }}

.markdownlint.yaml

@@ -1,6 +1,6 @@
-{
-  "MD007": { "indent": 4 },
-  "MD013": false,
-  "MD024": false,
-  "MD029": { "style": one },
-}
+MD007:
+  indent: 4
+MD013: false
+MD024: false
+MD029:
+  style: one

.vale.ini

@@ -1,7 +1,7 @@
 StylesPath = styles
 MinAlertLevel = warning
 
-Packages = https://github.com/stakater/vale-package/releases/download/v0.0.30/Stakater.zip
+Packages = https://github.com/stakater/vale-package/releases/download/v0.0.52/Stakater.zip
 Vocab = Stakater
 
 # Only check MarkDown files

README.md

@@ -47,7 +47,7 @@ Then access the docs on [`localhost:8080`](localhost:8080).
 
 ### Run commands locally
 
-Use [virtualenvwrapper](https://virtualenvwrapper.readthedocs.io/en/latest/install.html) to set up Python virtual environment.
+Use [`virtualenvwrapper`](https://virtualenvwrapper.readthedocs.io/en/latest/install.html) to set up Python virtual environment.
 
 Install [Python 3](https://www.python.org/downloads/).
 
@@ -59,7 +59,7 @@ Then run below script to prepare theme from local and common theme resources. It
 ./prepare_theme.sh
 ```
 
-Finally, serve the docs using the built-in web server which is based on Python http server - note that the production build will use Nginx instead:
+Finally, serve the docs using the built-in web server which is based on Python http server - note that the production build will use nginx instead:
 
 ```bash
 mkdocs serve
@@ -77,7 +77,7 @@ if you want to make theme changes with live reload, you can use `--watch-theme`
 mkdocs serve --watch-theme
 ```
 
-Then, you can make changes in `content` or `dist/_theme` folder. Please note that `dist/_theme` is a build folder and any changes made here will be lost if you do not move them to theme_common or theme_override folder.
+Then, you can make changes in `content` or `dist/_theme` folder. Please note that `dist/_theme` is a build folder and any changes made here will be lost if you do not move them to `theme_common` or `theme_override` folder.
 
 ### QA Checks
 

content/changelog.md

@@ -46,7 +46,7 @@
 
 #### Feature
 
-- Added support for configuring external keycloak in integrationconfig.
+- Added support for configuring external keycloak in `integrationconfig`.
 - Added free tier support that allows creation of 2 tenants without license.
 
 ## v0.10.x
@@ -145,7 +145,7 @@
 
 ### v0.8.3
 
-- fix: Reconcile namespaces when the group spec for tenants is changed, so new rolebindings can be created for them
+- fix: Reconcile namespaces when the group spec for tenants is changed, so new `rolebindings` can be created for them
 
 ### v0.8.1
 
@@ -225,7 +225,7 @@
 
 ### v0.5.3
 
-- fix: Add support for parameters in Helm chartRepository in templates
+- fix: Add support for parameters in Helm `chartRepository` in templates
 
 ### v0.5.2
 

content/crds-api-reference/integration-config.md

@@ -174,11 +174,11 @@ kubectl -n multi-tenant-operator create secret tls <tls-secret-name> --key=<path
 
 Integration config will be managing the following resources required for console GUI:
 
-- `MTO Postgresql` resources.
-- `MTO Prometheus` resources.
-- `MTO Opencost` resources.
-- `MTO Console, Gateway, Keycloak` resources.
-- `Showback` cronjob.
+- `MTO Postgresql` resources
+- `MTO Prometheus` resources
+- `MTO Opencost` resources
+- `MTO Console, Gateway, Keycloak` resources
+- `Showback` cron-job
 
 Details on console GUI and showback can be found [here](../explanation/console.md)
 
@@ -283,11 +283,11 @@ rbac:
 
 ##### Default
 
-This field contains roles that will be used to create default roleBindings for each namespace that belongs to tenants. These roleBindings are only created for a namespace if that namespace isn't already matched by the `custom` field below it. Therefore, it is required to have at least one role mentioned within each of its three subfields: `owner`, `editor`, and `viewer`. These 3 subfields also correspond to the member fields of the [Tenant CR](./tenant.md#tenant)
+This field contains roles that will be used to create default `roleBindings` for each namespace that belongs to tenants. These `roleBindings` are only created for a namespace if that namespace isn't already matched by the `custom` field below it. Therefore, it is required to have at least one role mentioned within each of its three subfields: `owner`, `editor`, and `viewer`. These 3 subfields also correspond to the member fields of the [Tenant CR](./tenant.md#tenant)
 
 ##### Custom
 
-An array of custom roles. Similar to the `default` field, you can mention roles within this field as well. However, the custom roles also require the use of a `labelSelector` for each iteration within the array. The roles mentioned here will only apply to the namespaces that are matched by the labelSelector. If a namespace is matched by 2 different labelSelectors, then both roles will apply to it. Additionally, roles can be skipped within the labelSelector. These missing roles are then inherited from the `default` roles field . For example, if the following custom roles arrangement is used:
+An array of custom roles. Similar to the `default` field, you can mention roles within this field as well. However, the custom roles also require the use of a `labelSelector` for each iteration within the array. The roles mentioned here will only apply to the namespaces that are matched by the `labelSelector`. If a namespace is matched by 2 different `labelSelectors`, then both roles will apply to it. Additionally, roles can be skipped within the `labelSelector`. These missing roles are then inherited from the `default` roles field . For example, if the following custom roles arrangement is used:
 
 ```yaml
 custom:
@@ -362,7 +362,7 @@ For example:
 
 ##### Groups
 
-`privileged.groups:` Contains names of the groups that are allowed to perform CRUD operations on namespaces present on the cluster. Users in the specified group(s) will be able to perform these operations without MTO getting in their way. MTO does not interfere even with the deletion of privilegedNamespaces.
+`privileged.groups:` Contains names of the groups that are allowed to perform CRUD operations on namespaces present on the cluster. Users in the specified group(s) will be able to perform these operations without MTO getting in their way. MTO does not interfere even with the deletion of `privilegedNamespaces`.
 
 !!! note
     User `kube:admin` is bypassed by default to perform operations as a cluster admin, this includes operations on all the namespaces.
@@ -499,7 +499,7 @@ argocd:
 
 ### Vault
 
-[Vault](https://www.vaultproject.io/) is used to secure, store and tightly control access to tokens, passwords, certificates, encryption keys for protecting secrets and other sensitive data using a UI, CLI, or HTTP API.
+[Vault](https://www.vaultproject.io/) is used to secure, store and tightly control access to tokens, passwords, certificates, encryption keys for protecting secrets and other sensitive data using a UI, CLI, or http API.
 
 If `vault` is configured on a cluster, then Vault configuration can be enabled.
 

content/explanation/console.md

@@ -119,7 +119,7 @@ The Showback feature is an essential financial governance tool, providing detail
 
 Administrators have overarching access to the console, including the ability to view all namespaces and tenants. They have exclusive access to the IntegrationConfig, allowing them to view all the settings and integrations.
 
-![integrationConfig](../images/integrationConfig.png)
+![integration Config](../images/integrationConfig.png)
 
 ### Tenant Users
 

content/explanation/multi-tenancy-vault.md

@@ -2,7 +2,7 @@
 
 ## Vault Multitenancy
 
-HashiCorp Vault is an identity-based secret and encryption management system. Vault validates and authorizes a system's clients (users, machines, apps) before providing them access to secrets or stored sensitive data.
+Hashicorp Vault is an identity-based secret and encryption management system. Vault validates and authorizes a system's clients (users, machines, apps) before providing them access to secrets or stored sensitive data.
 
 ## Vault integration in Multi Tenant Operator
 

content/how-to-guides/deploying-private-helm-charts.md

@@ -53,7 +53,7 @@ Multi Tenant Operator will pick up the credentials from the mentioned namespace
 
 Afterward, Bill can see that manifests in the chart have been successfully created in all label matching namespaces.
 
-## Deploying Helm Chart to Namespaces via TemplateGroupInstances from HTTPS Registry
+## Deploying Helm Chart to Namespaces via TemplateGroupInstances from https Registry
 
 Bill, the cluster admin, wants to deploy a helm chart from `HTTPS` registry in namespaces where certain labels exists.
 

content/how-to-guides/distributing-secrets-using-sealed-secret-template.md

@@ -71,7 +71,7 @@ spec:
 
 Bill has added support for a new label `distribute-image-pull-secret: true"` for tenant projects/namespaces, now MTO will add that label depending on the used field.
 
-Finally, Bill creates a `TemplateGroupInstance` which will deploy the sealed secrets using the newly created project label and template.
+Finally, Bill creates a `TemplateGroupInstance` which will deploy the Sealed Secrets using the newly created project label and template.
 
 ```yaml
 apiVersion: tenantoperator.stakater.com/v1alpha1
@@ -86,4 +86,4 @@ spec:
   sync: true
 ```
 
-MTO will now deploy the sealed secrets mentioned in `Template` to namespaces which have the mentioned label. The rest of the work to deploy secret from a sealed secret has to be done by Sealed Secrets Controller.
+MTO will now deploy the Sealed Secrets mentioned in `Template` to namespaces which have the mentioned label. The rest of the work to deploy secret from a Sealed Secret has to be done by Sealed Secrets Controller.

content/how-to-guides/enabling-multi-tenancy-argocd.md

@@ -127,7 +127,7 @@ Users belonging to the tenant group will now see only applications created by th
 !!! note
     For ArgoCD Multi Tenancy to work properly, any default roles or policies attached to all users must be removed.
 
-## Preventing ArgoCD from Syncing Certain Namespaced Resources
+## Preventing ArgoCD from Syncing Certain Name-spaced Resources
 
 To prevent tenants from syncing ResourceQuota and LimitRange resources to their namespaces, administrators can specify these resources in the blacklist section of the ArgoCD configuration in the [IntegrationConfig](../crds-api-reference/integration-config.md):
 

content/how-to-guides/enabling-multi-tenancy-vault.md

@@ -1,6 +1,6 @@
 # Configuring Vault in IntegrationConfig
 
-[Vault](https://www.vaultproject.io/) is used to secure, store and tightly control access to tokens, passwords, certificates, and encryption keys for protecting secrets and other sensitive data using a UI, CLI, or HTTP API.
+[Vault](https://www.vaultproject.io/) is used to secure, store and tightly control access to tokens, passwords, certificates, and encryption keys for protecting secrets and other sensitive data using a UI, CLI, or http API.
 
 To enable Vault multi-tenancy, a role has to be created in Vault under [Kubernetes authentication](https://developer.hashicorp.com/vault/docs/auth/kubernetes) with the following permissions:
 

content/index.md

@@ -36,9 +36,9 @@ Multi Tenant Operator binds existing ClusterRoles to the Tenant's Namespaces use
 
 Multi Tenant Operator is also able to leverage existing groups in Kubernetes and OpenShift, or external groups synced from 3rd party identity management systems, for maintaining Tenant membership in your organization's current user management system.
 
-## HashiCorp Vault Multitenancy
+## Hashicorp Vault Multitenancy
 
-Multi Tenant Operator extends the tenants permission model to HashiCorp Vault where it can create Vault paths and greatly ease the overhead of managing RBAC in Vault. Tenant users can manage their own secrets without the concern of someone else having access to their Vault paths.
+Multi Tenant Operator extends the tenants permission model to Hashicorp Vault where it can create Vault paths and greatly ease the overhead of managing RBAC in Vault. Tenant users can manage their own secrets without the concern of someone else having access to their Vault paths.
 
 More details on [Vault Multitenancy](./how-to-guides/enabling-multi-tenancy-vault.md)
 
@@ -104,7 +104,7 @@ More details on [Sandboxes](./tutorials/tenant/create-sandbox.md)
 
 Multi Tenant Operator supports cloning of secrets and configmaps from one namespace to another namespace based on label selectors. It uses templates to enable users to provide reference to secrets and configmaps. It uses a template group instance to distribute those secrets and namespaces in matching namespaces, even if namespaces belong to different tenants. If template instance is used then the resources will only be mapped if namespaces belong to same tenant.
 
-More details on [Copying Secrets and ConfigMaps](./tutorials/distributing-resources/copying-resources.md)
+More details on [Copying Secrets and Configmaps](./tutorials/distributing-resources/copying-resources.md)
 
 ## Self-Service
 

content/installation/kubernetes.md

@@ -19,7 +19,7 @@ This document contains instructions on installing, uninstalling and configuring
 
 ## Installing via Helm CLI
 
-* Public Helm Chart of MTO is available at [Stakater GHCR Packages](https://github.com/orgs/stakater/packages/container/package/public/charts/multi-tenant-operator) and available Helm options can be seen at [MTO Helm Chart Options](./helm-values.md)
+* Public Helm Chart of MTO is available at [Stakater ghcr Packages](https://github.com/orgs/stakater/packages/container/package/public/charts/multi-tenant-operator) and available Helm options can be seen at [MTO Helm Chart Options](./helm-values.md)
 
 * Use `helm install` command to install MTO helm chart. Here, `bypassedGroups` has the names of groups which are designated as Cluster Admins in your cluster. For this example, we will use `system:masters`