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

.github/workflows/closed_pr.yaml

@@ -7,6 +7,6 @@ on:
 
 jobs:
   push:
-    uses: stakater/.github/.github/workflows/[email protected].38
+    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

@@ -5,6 +5,8 @@ on:
 
 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

@@ -8,24 +8,25 @@ on:
 
 jobs:
   doc_qa:
-    uses: stakater/.github/.github/workflows/[email protected].38
+    uses: stakater/.github/.github/workflows/[email protected].117
     with:
       MD_CONFIG: .github/md_config.json
-      DOC_SRC: content
+      DOC_SRC: content README.md
       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].38
+    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
+      CONTAINER_REGISTRY_URL: ghcr.io/stakater
     secrets:
-      CONTAINER_REGISTRY_URL: ${{ secrets.STAKATER_NEXUS_PREPROD_REGISTRY }}
-      CONTAINER_REGISTRY_USERNAME: ${{ secrets.STAKATER_NEXUS_PREPROD_USERNAME }}
-      CONTAINER_REGISTRY_PASSWORD: ${{ secrets.STAKATER_NEXUS_PREPROD_PASSWORD }}
+      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 }}
-  deploy_doc:
-    uses: stakater/.github/.github/workflows/[email protected]
-    secrets:
-      GH_TOKEN: ${{ secrets.STAKATER_GITHUB_TOKEN }}
+      DOCKER_SECRETS: GIT_AUTH_TOKEN=${{ secrets.PUBLISH_TOKEN }}

.github/workflows/push.yaml

@@ -8,6 +8,8 @@ on:
 
 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].38
+    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].38
+    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: ${{ secrets.STAKATER_NEXUS_PREPROD_REGISTRY }}
-      CONTAINER_REGISTRY_USERNAME: ${{ secrets.STAKATER_NEXUS_PREPROD_USERNAME }}
-      CONTAINER_REGISTRY_PASSWORD: ${{ secrets.STAKATER_NEXUS_PREPROD_PASSWORD }}
+      CONTAINER_REGISTRY_URL: ghcr.io/stakater
+      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 }}

.gitignore

@@ -20,6 +20,7 @@ node_modules
 
 # Build files
 site/
+./mkdocs.yml
 
-
-.idea
+.idea
+styles

.gitmodules

@@ -1,3 +1,3 @@
-[submodule "vocabulary"]
-	path = vocabulary
-	url = [email protected]:stakater/vocabulary.git
+[submodule "theme_common"]
+	path = theme_common
+	url = [email protected]:stakater/stakater-docs-mkdocs-theme.git

.markdownlint.yaml

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

.vale.ini

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

Dockerfile

@@ -1,5 +1,5 @@
 # syntax=docker/dockerfile:1
-FROM nginxinc/nginx-unprivileged:1.24-alpine
+FROM nginxinc/nginx-unprivileged:1.27-alpine
 WORKDIR /usr/share/nginx/html/
 
 # copy the entire application

README.md

@@ -1,2 +1,3 @@
 # Multi Tenant Operator Documentation
+
 Documentation for [Multi Tenant Operator](https://www.stakater.com/mto)

content/changelog.md

@@ -41,7 +41,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
 
@@ -121,7 +121,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/faq.md

@@ -6,7 +6,7 @@
 
 ## Q. How do I deploy cluster-scoped resource via the ArgoCD integration?
 
-**A.** Multi-Tenant Operator's ArgoCD Integration allows configuration of which cluster-scoped resources can be deployed, both globally and on a per-tenant basis. For a global whitelist that applies to all tenants, you can add both resource `group` and  `kind` to the [IntegrationConfig's](./how-to-guides/integration-config.md#argocd) `spec.argocd.clusterResourceWhitelist` field. Alternatively, you can set this up on a tenant level by configuring the same details within a [Tenant's](./how-to-guides/tenant.md) `spec.argocd.appProject.clusterResourceWhitelist` field. For more details, check out the [ArgoCD integration use cases](./tutorials/argocd/enabling-multi-tenancy-argocd.md#allow-argocd-to-sync-certain-cluster-wide-resources)
+**A.** Multi-Tenant Operator's ArgoCD Integration allows configuration of which cluster-scoped resources can be deployed, both globally and on a per-tenant basis. For a global deny list that applies to all tenants, you can add both resource `group` and  `kind` to the [IntegrationConfig's](./how-to-guides/integration-config.md#argocd) `spec.argocd.clusterResourceWhitelist` field. Alternatively, you can set this up on a tenant level by configuring the same details within a [Tenant's](./how-to-guides/tenant.md) `spec.argocd.appProject.clusterResourceWhitelist` field. For more details, check out the [ArgoCD integration use cases](./tutorials/argocd/enabling-multi-tenancy-argocd.md#allow-argocd-to-sync-certain-cluster-wide-resources)
 
 ## Q. InvalidSpecError: application repo \<repo\> is not permitted in project \<project\>
 

content/features.md

@@ -10,9 +10,9 @@ Multi Tenant Operator binds existing ClusterRoles to the Tenant's Namespaces use
 
 Multi Tenant Operator is also able to leverage existing OpenShift groups 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](./tutorials/vault/enabling-multi-tenancy-vault.md)
 
@@ -65,7 +65,7 @@ More details on [Hibernation](./tutorials/tenant/tenant-hibernation.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 [Distributing Secrets and ConfigMaps](./reference-guides/distributing-resources.md)
+More details on [Distributing Secrets and Configmaps](./reference-guides/distributing-resources.md)
 
 ## Self-Service
 

content/how-to-guides/integration-config.md

@@ -141,11 +141,11 @@ tenantRoles:
 
 ### 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:
@@ -341,7 +341,7 @@ If enabled, then admins have to provide secret and URL of RHSSO.
 
 ## 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/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 OpenShift groups 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](./tutorials/vault/enabling-multi-tenancy-vault.md)
 
@@ -91,7 +91,7 @@ More details on [Hibernation](./tutorials/tenant/tenant-hibernation.md#hibernati
 
 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 [Distributing Secrets and ConfigMaps](./reference-guides/distributing-resources.md)
+More details on [Distributing Secrets and Configmaps](./reference-guides/distributing-resources.md)
 
 ## Self-Service
 

content/installation.md

@@ -4,9 +4,9 @@ This document contains instructions on installing, uninstalling and configuring
 
 1. [OpenShift OperatorHub UI](#installing-via-operatorhub-ui)
 
-2. [CLI/GitOps](#installing-via-cli-or-gitops)
+1. [CLI/GitOps](#installing-via-cli-or-gitops)
 
-3. [Uninstall](#uninstall-via-operatorhub-ui)
+1. [Uninstall](#uninstall-via-operatorhub-ui)
 
 ## Requirements
 

content/integration-config.md

@@ -141,11 +141,11 @@ tenantRoles:
 
 ### 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 namespaces 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](./customresources.md#_2-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 namespaces 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](./customresources.md)
 
 ### 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:
@@ -341,7 +341,7 @@ If enabled, than admins have to provide secret and URL of RHSSO.
 
 ## 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/reference-guides/deploying-templates.md

@@ -3,8 +3,8 @@
 Multi Tenant Operator has three Custom Resources which can cover this need using the `Template` CR, depending upon the conditions and preference.
 
 1. TemplateGroupInstance
-2. TemplateInstance
-3. Tenant
+1. TemplateInstance
+1. Tenant
 
 Stakater Team, however, encourages the use of `TemplateGroupInstance` to distribute resources in multiple namespaces as it is optimized for better performance.
 
@@ -57,7 +57,7 @@ NAME             STATE    AGE
 docker-secret    Active   2m
 ```
 
-`TemplateGroupInstance` can also target specific tenants or all tenant namespaces under a single yaml definition.
+`TemplateGroupInstance` can also target specific tenants or all tenant namespaces under a single YAML definition.
 
 ### TemplateGroupInstance for multiple Tenants
 

content/reference-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/reference-guides/distributing-secrets.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.