ci: gha to check for typos in docs

.github/workflows/website.yaml

@@ -1,4 +1,4 @@
-name: generate_website
+name: website
 
 on:
   push:
@@ -14,12 +14,13 @@ on:
       - ".github/workflows/website.yaml"
       - "website/**"
 
-permissions:
-  contents: write
+permissions: read-all
 
 jobs:
   deploy:
     runs-on: ubuntu-22.04
+    permissions:
+      contents: write
     defaults:
       run:
         working-directory: website
@@ -29,7 +30,7 @@ jobs:
         with:
           egress-policy: audit
 
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v3.5.2
 
       - name: Setup Node
         uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4.1.0
@@ -59,3 +60,17 @@ jobs:
           github_token: ${{ secrets.GITHUB_TOKEN }}
           publish_dir: ./website/build
           destination_dir: ./website
+
+  check_typos:
+    runs-on: ubuntu-22.04
+    steps:
+      - name: Harden Runner
+        uses: step-security/harden-runner@91182cccc01eb5e619899d80e4e971d6181294a7 # v2.10.1
+        with:
+          egress-policy: audit
+
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v3.5.2
+
+      - uses: crate-ci/typos@b74202f74b4346efdbce7801d187ec57b266bac8 # v1.27.3
+        with:
+          files: ./website/docs ./website/versioned_docs

_typos.toml

@@ -0,0 +1,4 @@
+[default]
+extend-ignore-identifiers-re = [
+    "ANDed",
+]

website/docs/audit.md

@@ -116,7 +116,7 @@ In addition to information on the violated constraint, violating resource, and v
 audit log entries also contain:
 
 * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits
-* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations
+* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations
 
 Limitations of getting violations from audit logs:
 
@@ -140,7 +140,7 @@ This feature uses publish and subscribe (pubsub) model that allows Gatekeeper to
 Limitations/drawbacks of getting violations using pubsub channel:
 
 - There is an inherent risk of messages getting dropped. You might not receive all the published violations.
-- Additional dependancy on pubsub broker. 
+- Additional dependency on pubsub broker. 
 
 ## Running Audit
 For more details on how to deploy audit and 

website/docs/failing-closed.md

@@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe
 
 ## Why Is This Hard?
 
-In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns.
+In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns.

website/docs/gator.md

@@ -548,17 +548,17 @@ Certain templates require [replicating data](sync.md) into OPA to enable correct
 ```
 This annotation contains two requirements. Requirement 1 contains two clauses. Syncing resources of group1, version3, kind1 (drawn from clause 1) would be sufficient to fulfill Requirement 1. So, too, would syncing resources of group3, version3, kind4 (drawn from clause 2). Syncing resources of group1, version1, and kind3 would not be, however.
 
-Requirement 2 is simpler: it denotes that group5, version5, kind5 must be synced for the policy to work properly. 
+Requirement 2 is simpler: it denotes that group5, version5, kind5 must be synced for the policy to work properly.
 
-This template annotation is descriptive, not prescriptive. The prescription of which resources to sync is done in `SyncSet` resources and/or the Gatekeeper `Config` resource. The management of these various requirements can get challenging as the number of templates requiring replicated data increases. 
+This template annotation is descriptive, not prescriptive. The prescription of which resources to sync is done in `SyncSet` resources and/or the Gatekeeper `Config` resource. The management of these various requirements can get challenging as the number of templates requiring replicated data increases.
 
 `gator sync test` aims to mitigate this challenge by enabling the user to check that their sync configuration is correct. The user passes in a set of Constraint Templates, GVK Manifest listing GVKs supported by the cluster, SyncSets, and/or a Gatekeeper Config, and the command will determine which requirements enumerated by the Constraint Templates are unfulfilled by the cluster and SyncSet(s)/Config.
 
 ### Usage
 
 #### Specifying Inputs
 
-`gator sync test` expects a `--filename` or `--image` flag, or input fron stdin. The flags can be used individually, in combination, and/or repeated.
+`gator sync test` expects a `--filename` or `--image` flag, or input from stdin. The flags can be used individually, in combination, and/or repeated.
 
 ```
 gator sync test --filename="template.yaml" –-filename="syncsets/" --filename="manifest.yaml"
@@ -590,7 +590,7 @@ spec:
         kinds: ["Kind4", "Kind5"]
 ```
 
-Optionally, the `--omit-gvk-manifest` flag can be used to skip the requirement of providing a manifest of supported GVKs for the cluster. If this is provided, all GVKs will be assumed to be supported by the cluster. If this assumption is not true, then the given config and templates may cause caching errors or incorrect evaluation on the cluster despite passing this command. 
+Optionally, the `--omit-gvk-manifest` flag can be used to skip the requirement of providing a manifest of supported GVKs for the cluster. If this is provided, all GVKs will be assumed to be supported by the cluster. If this assumption is not true, then the given config and templates may cause caching errors or incorrect evaluation on the cluster despite passing this command.
 
 #### Exit Codes
 

website/docs/metrics.md

@@ -73,7 +73,7 @@ To see how long it takes to review a constraint kind at admission time, enable t
 }
 ```
 
-In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environemnt setup, like whether tracing was enabled (`TraceEnabled`).
+In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environment setup, like whether tracing was enabled (`TraceEnabled`).
 
 #### Caveats
 

website/versioned_docs/version-v3.10.x/audit.md

@@ -104,7 +104,7 @@ In addition to information on the violated constraint, violating resource, and v
 audit log entries also contain:
 
 * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits
-* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations
+* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations
 
 #### Other Event Types
 

website/versioned_docs/version-v3.10.x/failing-closed.md

@@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe
 
 ## Why Is This Hard?
 
-In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns.
+In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns.

website/versioned_docs/version-v3.10.x/howto.md

@@ -150,4 +150,4 @@ The `input.review` object stores the [admission request](https://pkg.go.dev/k8s.
 - `uid`: The request's unique identifier. This cannot be populated by Kubernetes for audit.
 - `userInfo`: The request's user's information such as `username`, `uid`, `groups`, `extra`. This cannot be populated by Kubernetes for audit.
 
-> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. 
+> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources.

website/versioned_docs/version-v3.11.x/audit.md

@@ -111,7 +111,7 @@ In addition to information on the violated constraint, violating resource, and v
 audit log entries also contain:
 
 * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits
-* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations
+* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations
 
 #### Other Event Types
 

website/versioned_docs/version-v3.11.x/failing-closed.md

@@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe
 
 ## Why Is This Hard?
 
-In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns.
+In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns.

website/versioned_docs/version-v3.11.x/howto.md

@@ -150,4 +150,4 @@ The `input.review` object stores the [admission request](https://pkg.go.dev/k8s.
 - `uid`: The request's unique identifier. This cannot be populated by Kubernetes for audit.
 - `userInfo`: The request's user's information such as `username`, `uid`, `groups`, `extra`. This cannot be populated by Kubernetes for audit.
 
-> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. 
+> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources.

website/versioned_docs/version-v3.12.x/audit.md

@@ -111,7 +111,7 @@ In addition to information on the violated constraint, violating resource, and v
 audit log entries also contain:
 
 * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits
-* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations
+* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations
 
 #### Other Event Types
 

website/versioned_docs/version-v3.12.x/failing-closed.md

@@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe
 
 ## Why Is This Hard?
 
-In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns.
+In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns.

website/versioned_docs/version-v3.12.x/howto.md

@@ -150,4 +150,4 @@ The `input.review` object stores the [admission request](https://pkg.go.dev/k8s.
 - `uid`: The request's unique identifier. This cannot be populated by Kubernetes for audit.
 - `userInfo`: The request's user's information such as `username`, `uid`, `groups`, `extra`. This cannot be populated by Kubernetes for audit.
 
-> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. 
+> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources.

website/versioned_docs/version-v3.13.x/audit.md

@@ -115,7 +115,7 @@ In addition to information on the violated constraint, violating resource, and v
 audit log entries also contain:
 
 * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits
-* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations
+* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations
 
 Limitations of getting violations from audit logs:
 
@@ -139,7 +139,7 @@ This feature uses publish and subscribe (pubsub) model that allows Gatekeeper to
 Limitations/drawbacks of getting violations using pubsub channel:
 
 - There is an inherent risk of messages getting dropped. You might not receive all the published violations.
-- Additional dependancy on pubsub broker. 
+- Additional dependency on pubsub broker. 
 
 ## Running Audit
 For more details on how to deploy audit and 

website/versioned_docs/version-v3.13.x/failing-closed.md

@@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe
 
 ## Why Is This Hard?
 
-In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns.
+In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns.

website/versioned_docs/version-v3.13.x/howto.md

@@ -150,4 +150,4 @@ The `input.review` object stores the [admission request](https://pkg.go.dev/k8s.
 - `uid`: The request's unique identifier. This cannot be populated by Kubernetes for audit.
 - `userInfo`: The request's user's information such as `username`, `uid`, `groups`, `extra`. This cannot be populated by Kubernetes for audit.
 
-> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. 
+> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources.

website/versioned_docs/version-v3.13.x/metrics.md

@@ -73,7 +73,7 @@ To see how long it takes to review a constraint kind at admission time, enable t
 }
 ```
 
-In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environemnt setup, like whether tracing was enabled (`TraceEnabled`).
+In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environment setup, like whether tracing was enabled (`TraceEnabled`).
 
 #### Caveats
 

website/versioned_docs/version-v3.14.x/audit.md

@@ -115,7 +115,7 @@ In addition to information on the violated constraint, violating resource, and v
 audit log entries also contain:
 
 * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits
-* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations
+* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations
 
 Limitations of getting violations from audit logs:
 
@@ -139,7 +139,7 @@ This feature uses publish and subscribe (pubsub) model that allows Gatekeeper to
 Limitations/drawbacks of getting violations using pubsub channel:
 
 - There is an inherent risk of messages getting dropped. You might not receive all the published violations.
-- Additional dependancy on pubsub broker. 
+- Additional dependency on pubsub broker. 
 
 ## Running Audit
 For more details on how to deploy audit and