pepr 0.21.0 → 0.22.0

package/website/assets/scss/_styles_project.scss

@@ -1,7 +0,0 @@
-code {
-  --bs-code-color: #{$secondary};
-}
-
-.td-navbar .navbar-brand svg {
-    width: fit-content;
-}

package/website/assets/scss/_variables_project.scss

@@ -1 +0,0 @@
-$secondary: #EFCA81;

package/website/content/en/docs/OnSchedule.md

@@ -1,86 +0,0 @@
----
-title: OnSchedule
-linkTitle: OnSchedule
----
-
-# OnSchedule
-
-The `OnSchedule` feature allows you to schedule and automate the execution of specific code at predefined intervals or schedules. This feature is designed to simplify recurring tasks and can serve as an alternative to traditional CronJobs. This code is designed to be run at the top level on a Capability, not within a function like `When`. 
-  
-> **Note -** To use this feature in dev mode you MUST set `PEPR_WATCH_MODE="true"`. This is because the scheduler only runs on the watch controller and the watch controller is not started by default in dev mode.
-
-For example: `PEPR_WATCH_MODE="true" npx pepr dev`
-
-## Best Practices
-
-`OnSchedule` is designed for targeting intervals equal to or larger than 30 seconds due to the storage mechanism used to archive schedule info.
-  
-## Usage
-
-Create a recurring task execution by calling the OnSchedule function with the following parameters:
-
-**name** - The unique name of the schedule.
-
-**every** - An integer that represents the frequency of the schedule in number of _units_.
-
-**unit** - A string specifying the time unit for the schedule (e.g., `seconds`, `minute`, `minutes`, `hour`, `hours`). 
-
-**startTime** - (Optional) A UTC timestamp indicating when the schedule should start. All date times must be provided in GMT. If not specified the schedule will start when the schedule store reports ready.
-
-**run** - A function that contains the code you want to execute on the defined schedule.  
-
-**completions** - (Optional) An integer indicating the maximum number of times the schedule should run to completion. If not specified the schedule will run indefinitely.
-
-
-## Examples
-
-Update the curr ConfigMap every 15 seconds and use the store to track the current count:
-
-```typescript
-OnSchedule({
-    name: "hello-interval",
-    every: 30,
-    unit: "seconds",
-    run: async () => {
-      Log.info("Wait 30 seconds and create/update a ConfigMap");
-
-      try {
-        await K8s(kind.ConfigMap).Apply({
-          metadata: {
-            name: "last-updated",
-            namespace: "default",
-          },
-          data: {
-            count: `${new Date()}`,
-          },
-        });
-
-      } catch (error) {
-        Log.error(error, "Failed to apply ConfigMap using server-side apply.");
-      }
-    },
-  });
-```
-
-Refresh an AWSToken every 24 hours, with a delayed start of 30 seconds, running a total of 3 times:
-
-```typescript
-
-OnSchedule({
-  name: "refresh-aws-token",
-  every: 24,
-  unit: "hours",
-  startTime: new Date(new Date().getTime() + 1000 * 30),
-  run: async () => {
-    await RefreshAWSToken();
-  },
-  completions: 3,
-});
-```
-
-## Advantages 
-
-- Simplifies scheduling recurring tasks without the need for complex CronJob configurations.
-- Provides flexibility to define schedules in a human-readable format.
-- Allows you to execute code with precision at specified intervals.
-- Supports limiting the number of schedule completions for finite tasks.

package/website/content/en/docs/_index.md

@@ -1,9 +0,0 @@
----
-title: Overview
-linkTitle: Documentation
-menu: {main: {weight: 1}}
----
-
-## What is Pepr?
-
-Pepr functions as both a Mutating and Validating Admission Webhook, offering a fluent API that facilitates real-time resource alterations and the establishment and enforcement of policies on Kubernetes resources. Its design is not only lightweight but also includes an integrated Kubernetes client, ensuring a straightforward and effective user experience for additional interactions with Kubernetes.

package/website/content/en/docs/cli.md

@@ -1,83 +0,0 @@
----
-title: CLI
-linkTitle: CLI
----
-# Pepr CLI
-
-## pepr init
-
-Initialize a new Pepr Module.
-
-**Options:**
-
-- `-l, --log-level [level]` - Log level: debug, info, warn, error (default: "info")
-- `--skip-post-init` - Skip npm install, git init and VSCode launch
-
----
-
-## pepr update
-
-Update the current Pepr Module to the latest SDK version and update the global Pepr CLI to the same version.
-
-**Options:**
-
-- `-l, --log-level [level]` - Log level: debug, info, warn, error (default: "info")
-- `--skip-template-update` - Skip updating the template files
-
----
-
-## pepr dev
-
-Connect a local cluster to a local version of the Pepr Controller to do real-time debugging of your module. Note
-the `pepr dev` assumes a K3d cluster is running by default. If you are working with Kind or another docker-based
-K8s distro, you will need to pass the `--host host.docker.internal` option to `pepr dev`. If working with a remote
-cluster you will have to give Pepr a host path to your machine that is reachable from the K8s cluster.
-
-**Options:**
-
-- `-l, --log-level [level]` - Log level: debug, info, warn, error (default: "info")
-- `-h, --host [host]` - Host to listen on (default: "host.k3d.internal")
-- `--confirm` - Skip confirmation prompt
-
----
-
-## pepr deploy
-
-Deploy the current module into a Kubernetes cluster, useful for CI systems. Not recommended for production use.
-
-**Options:**
-
-- `-l, --log-level [level]` - Log level: debug, info, warn, error (default: "info")
-- `-i, --image [image]` - Override the image tag
-- `--confirm` - Skip confirmation prompt
-
----
-
-## pepr monitor
-
-Monitor Validations for a given Pepr Module.
-
-Usage: 
-```bash
-npx pepr monitor [options] <module-uuid>
-```
-
-**Options:**
-- `-l, --log-level [level]` - Log level: debug, info, warn, error (default: "info")
-- `-h, --help` - Display help for command
-
----
-
-## pepr build
-
-Create a [zarf.yaml](https://zarf.dev) and K8s manifest for the current module. This includes everything needed to deploy Pepr and the current module into production environments.
-
-
-**Options:**
-
-- `-l, --log-level [level]` - Log level: debug, info, warn, error (default: "info")
-- `-e, --entry-point [file]` - Specify the entry point file to build with. (default: "pepr.ts")
-- `-n, --no-embed` - Disables embedding of deployment files into output module. Useful when creating library modules intended solely for reuse/distribution via NPM
-- `-r, --registry-info [<registry>/<username>]` - Registry Info: Image registry and username. Note: You must be signed into the registry
-- `-o, --output-dir [output directory]` - Define where to place build output
-- `--rbac-mode [admin|scoped]` - Rbac Mode: admin, scoped (default: admin) (choices: "admin", "scoped", default: "admin")

package/website/content/en/docs/codeSample.txt

@@ -1,31 +0,0 @@
----
-title: Code Sample
-description: Samples of code
----
-<!-- 
-In certain instances a markdown viewer may not display due to
-the '---' frontmatter block above. If you're one of those edge
-cases enclose the frontmatter at the top of this file entirely
-within a comment block just like this comment.
--->
-
-```bash
-echo "This is bash"
-```
-
-```javascript
-console.log('This is JS')
-```
-
-```go
-func main() {
-    fmt.Println("Go with language defined")
-}
-```
-
-```gherkin
-Scenario: Document a product
-Given there is documentation to publish
-When I review the documentation
-Then it will meet the Unicorn style
-```

package/website/content/en/docs/concepts.md

@@ -1,238 +0,0 @@
----
-title: Concepts
-linkTitle: Concepts
----
-
-# Pepr Module
-
-Each Pepr Module is it's own Typescript project, produced by [`pepr init`](./cli.md#pepr-init). Typically a module is maintained by a unique group or system. For example, a module for internal [Zarf](https://zarf.dev/) mutations would be different from a module for [Big Bang](https://p1.dso.mil/products/big-bang). An important idea with modules is that they are _wholly independent of one another_. This means that 2 different modules can be on completely different versions of Pepr and any other dependencies; their only interaction is through the standard K8s interfaces like any other webhook or controller.
-
-## Module development lifecycle
-
-1. **Create the module**:
-
-   Use [`pepr init`](./cli.md#pepr-init) to generate a new module.
-
-1. **Quickly validate system setup**:
-
-   Every new module includes a sample Pepr Capability called `HelloPepr`. By default,
-   this capability is deployed and monitoring the `pepr-demo` namespace. There is a sample
-   yaml also included you can use to see Pepr in your cluster. Here's the quick steps to do
-   that after `pepr init`:
-
-   ```bash
-   # cd to the newly-created Pepr module folder
-   cd my-module-name
-
-   # If you don't already have a local K8s cluster, you can set one up with k3d
-   npm run k3d-setup
-
-   # Launch pepr dev mode
-   # If using another local K8s distro instead of k3d, use `pepr dev --host host.docker.internal`
-   pepr dev
-
-   # From another terminal, apply the sample yaml
-   kubectl apply -f capabilities/hello-pepr.samples.yaml
-
-   # Verify the configmaps were transformed using kubectl, k9s or another tool
-   ```
-
-1. **Create your custom Pepr Capabilities**
-
-   Now that you have confirmed Pepr is working, you can now create new [capabilities](./capabilities.md). You'll also want to disable the `HelloPepr` capability in your module (`pepr.ts`) before pushing to production. You can disable by commenting out or deleting the `HelloPepr` variable below:
-
-   ```typescript
-   new PeprModule(cfg, [
-     // Remove or comment the line below to disable the HelloPepr capability
-     HelloPepr,
-
-     // Your additional capabilities go here
-   ]);
-   ```
-
-   _Note: if you also delete the `capabilities/hello-pepr.ts` file, it will be added again on the next [`pepr update`](./cli.md#pepr-update) so you have the latest examples usages from the Pepr SDK. Therefore, it is sufficient to remove the entry from your `pepr.ts` module
-   config._
-
-1. **Build and deploy the Pepr Module**
-
-   Most of the time, you'll likely be iterating on a module with `pepr dev` for real-time feedback and validation Once you are ready to move beyond the local dev environment, Pepr provides deployment and build tools you can use.
-
-   `pepr deploy` - you can use this command to build your module and deploy it into any K8s cluster your current `kubecontext` has access to. This setup is ideal for CI systems during testing, but is not recommended for production use. See [`pepr deploy`](./cli.md#pepr-deploy) for more info.
-
-## Advanced Module Configuration
-
-By default, when you run `pepr init`, the module is not configured with any additional options. Currently, there are 3 options you can configure:
-
-- `deferStart` - if set to `true`, the module will not start automatically. You will need to call `start()` manually. This is useful if you want to do some additional setup before the module controller starts. You can also use this to change the default port that the controller listens on.
-
-- `beforeHook` - an optional callback that will be called before every request is processed. This is useful if you want to do some additional logging or validation before the request is processed.
-
-- `afterHook` - an optional callback that will be called after every request is processed. This is useful if you want to do some additional logging or validation after the request is processed.
-
-You can configure each of these by modifying the `pepr.ts` file in your module. Here's an example of how you would configure each of these options:
-
-```typescript
-const module = new PeprModule(
-  cfg,
-  [
-    // Your capabilities go here
-  ],
-  {
-    deferStart: true,
-
-    beforeHook: req => {
-      // Any actions you want to perform before the request is processed, including modifying the request.
-    },
-
-    afterHook: res => {
-      // Any actions you want to perform after the request is processed, including modifying the response.
-    },
-  }
-);
-
-// Do any additional setup before starting the controller
-module.start();
-```
-
-# Capabilities
-
-A capability is set of related [actions](./actions.md) that work together to achieve a specific transformation or operation on Kubernetes resources. Capabilities are user-defined and can include one or more actions. They are defined within a Pepr module and can be used in both MutatingWebhookConfigurations and ValidatingWebhookConfigurations. A Capability can have a specific scope, such as mutating or validating, and can be reused in multiple Pepr modules.
-
-When you [`pepr init`](./cli.md#pepr-init), a `capabilities` directory is created for you. This directory is where you will define your capabilities. You can create as many capabilities as you need, and each capability can contain one or more actions. Pepr also automatically creates a `HelloPepr` capability with a number of example actions to help you get started.
-
-## Creating a Capability
-
-Define a new capability can be done via a [VSCode Snippet](https://code.visualstudio.com/docs/editor/userdefinedsnippets) generated during [`pepr init`](./cli.md#pepr-init).
-
-1. Create a new file in the `capabilities` directory with the name of your capability. For example, `capabilities/my-capability.ts`.
-
-1. Open the new file in VSCode and type `create` in the file. A suggestion should prompt you to generate the content from there.
-
-https://user-images.githubusercontent.com/882485/230897379-0bb57dff-9832-479f-8733-79e103703135.mp4
-
-_If you prefer not to use VSCode, you can also modify or copy the `HelloPepr` capability to meet your needs instead._
-
-
-## Reusable Capabilities
-
-Pepr has an NPM org managed by Defense Unicorns, `@pepr`, where capabilities are published for reuse in other Pepr Modules. You can find a list of published capabilities [here](https://www.npmjs.com/search?q=@pepr). You can also publish your own Pepr capabilities to NPM and import them.  A couple of things you'll want to be aware of:
-
-- Reuseable capability versions should use the format `0.x.x` or `0.12.x` as examples to determine compatibility with other reusable capabilities. Before `1.x.x`, we recommend binding to `0.x.x` if you can for maximum compatibility.
-
-- `pepr.ts` will still be used for local development, but you'll need to also publish an `index.ts` that exports your capabilities. When you build & publish the capability to NPM, you can use `npx pepr build -e index.ts` to generate the code needed for reuse by other Pepr modules.
-
-- See [Pepr Istio](https://github.com/defenseunicorns/pepr-istio) for an example of a reusable capability.
-
-
-# Actions
-
-An action is a discrete set of behaviors defined in a single function that acts on a given Kubernetes GroupVersionKind (GVK) passed in during the admission controller lifecycle. Actions are the atomic operations that are performed on Kubernetes resources by Pepr.
-
-For example, an action could be responsible for adding a specific label to a Kubernetes resource, or for modifying a specific field in a resource's metadata. Actions can be grouped together within a Capability to provide a more comprehensive set of operations that can be performed on Kubernetes resources.
-
-Actions are `Mutate()`, `Validate()`, or `Watch()`. Both Mutate and Validate actions run during the admission controller lifecycle, while Watch actions run in a separate controller that tracks changes to resources, including existing resources.
-
-Let's look at some example actions that are included in the `HelloPepr` capability that is created for you when you [`pepr init`](./cli.md#pepr-init):
-
----
-
-In this first example, Pepr is adding a label and annotation to a ConfigMap with tne name `example-1` when it is created. Comments are added to each line to explain in more detail what is happening.
-
-```ts
-// When(a.<Kind>) filters which GroupVersionKind (GVK) this action should act on.
-When(a.ConfigMap)
-  // This limits the action to only act on new resources.
-  .IsCreated()
-  // This limits the action to only act on resources with the name "example-1".
-  .WithName("example-1")
-  // Mutate() is where we define the actual behavior of this action.
-  .Mutate(request => {
-    // The request object is a wrapper around the K8s resource that Pepr is acting on.
-    request
-      // Here we are adding a label to the ConfigMap.
-      .SetLabel("pepr", "was-here")
-      // And here we are adding an annotation.
-      .SetAnnotation("pepr.dev", "annotations-work-too");
-
-    // Note that we are not returning anything here. This is because Pepr is tracking the changes in each action automatically.
-  });
-```
-
----
-
-In this example, a Validate action rejects any ConfigMap in the `pepr-demo` namespace that has no data.
-
-```ts
-When(a.ConfigMap)
-  .IsCreated()
-  .InNamespace("pepr-demo")
-  // Validate() is where we define the actual behavior of this action.
-  .Validate(request => {
-    // If data exists, approve the request.
-    if (request.Raw.data) {
-      return request.Approve();
-    }
-
-    // Otherwise, reject the request with a message and optional code.
-    return request.Deny("ConfigMap must have data");
-  });
-```
-
----
-
-In this example, a Watch action on the name and phase of any ConfigMap.Watch actions run in a separate controller that tracks changes to resources, including existing resources so that you can react to changes in real-time. It is important to note that Watch actions are not run during the admission controller lifecycle, so they cannot be used to modify or validate resources. They also may run multiple times for the same resource, so it is important to make sure that your Watch actions are idempotent. In a future release, Pepr will provide a better way to control when a Watch action is run to avoid this issue.
-
-```ts
-When(a.ConfigMap)
-  // Watch() is where we define the actual behavior of this action.
-  .Watch((cm, phase) => {
-    Log.info(cm, `ConfigMap ${cm.metadata.name} was ${phase}`);
-  });
-```
-
-```
-There are many more examples in the `HelloPepr` capability that you can use as a reference when creating your own actions. Note that each time you run [`pepr update`](./cli.md#pepr-update), Pepr will automatically update the `HelloPepr` capability with the latest examples and best practices for you to reference and test directly in your Pepr Module.
-```
-
-# Pepr Store: A Lightweight Key-Value Store for Pepr Modules
-
-The nature of admission controllers and general watch operations (the `Mutate`, `Validate` and `Watch` actions in Pepr) make some types of complex and long-running operations difficult. There are also times when you need to share data between different actions. While you could manually create your own K8s resources and manage their cleanup, this can be very hard to track and keep performant at scale. 
-
-The Pepr Store solves this by exposing a simple, [Web Storage API](https://developer.mozilla.org/en-US/docs/Web/API/Storage)-compatible mechanism for use within capabilities. Additionally, as Pepr runs multiple replicas of the admission controller along with a watch controller, the Pepr Store provides a unique way to share data between these different instances automatically.
-
-Each Pepr Capability has a `Store` instance that can be used to get, set and delete data as well as subscribe to any changes to the Store. Behind the scenes, all capability store instances in a single Pepr Module are stored within a single CRD in the cluster. This CRD is automatically created when the Pepr Module is deployed. Care is taken to make the read and write operations as efficient as possible by using K8s watches, batch processing and patch operations for writes.
-
-## Key Features
-
-- **Asynchronous Key-Value Store**: Provides an asynchronous interface for storing small amounts of data, making it ideal for sharing information between various actions and capabilities.
-- **Web Storage API Compatibility**: The store's API is aligned with the standard [Web Storage API](https://developer.mozilla.org/en-US/docs/Web/API/Storage), simplifying the learning curve.
-- **Real-time Updates**: The `.subscribe()` and `onReady()` methods enable real-time updates, allowing you to react to changes in the data store instantaneously.
-
-- **Automatic CRD Management**: Each Pepr Module has its data stored within a single Custom Resource Definition (CRD) that is automatically created upon deployment.
-- **Efficient Operations**: Pepr Store uses Kubernetes watches, batch processing, and patch operations to make read and write operations as efficient as possible.
-
-## Quick Start
-
-```typescript
-// Example usage for Pepr Store
-Store.setItem("example-1", "was-here");
-Store.setItem("example-1-data", JSON.stringify(request.Raw.data));
-Store.onReady(data => {
-  Log.info(data, "Pepr Store Ready");
-});
-const unsubscribe = Store.subscribe(data => {
-  Log.info(data, "Pepr Store Updated");
-  unsubscribe();
-});
-```
-
-## API Reference
-
-### Methods
-
-- `getItem(key: string)`: Retrieves a value by its key. Returns `null` if the key doesn't exist.
-- `setItem(key: string, value: string)`: Sets a value for a given key. Creates a new key-value pair if the key doesn't exist.
-- `removeItem(key: string)`: Deletes a key-value pair by its key.
-- `clear()`: Clears all key-value pairs from the store.
-- `subscribe(listener: DataReceiver)`: Subscribes to store updates.
-- `onReady(callback: DataReceiver)`: Executes a callback when the store is ready.

package/website/content/en/docs/customresources.md

@@ -1,167 +0,0 @@
----
-title: Custom Resources
-linkTitle: Custom Resources
----
-
-
-# Importing Custom Resources
-
-
-The [Kubernetes Fluent Client](https://github.com/defenseunicorns/kubernetes-fluent-client) supports the creation of TypeScript typings directly from Kubernetes Custom Resource Definitions (CRDs).  The files it generates can be directly incorporated into Pepr capabilities and provide a way to work with strongly-typed CRDs.
-
-For example (below), Istio CRDs can be imported and used as though they were intrinsic Kubernetes resources.
-
-
-## Generating TypeScript Types from CRDs
-
-Using the kubernetes-fluent-client to produce a new type looks like this:
-
-```bash
-npx kubernetes-fluent-client crd [source] [directory]
-```
-
-The `crd` command expects a `[source]`, which can be a URL or local file containing the `CustomResourceDefinition(s)`, and a `[directory]` where the generated code will live.
-
-The following example creates types for the Istio CRDs:
-
-```bash
-user@workstation$  npx kubernetes-fluent-client crd https://raw.githubusercontent.com/istio/istio/master/manifests/charts/base/crds/crd-all.gen.yaml crds
-
-Attempting to load https://raw.githubusercontent.com/istio/istio/master/manifests/charts/base/crds/crd-all.gen.yaml as a URL
-
-- Generating extensions.istio.io/v1alpha1 types for WasmPlugin
-- Generating networking.istio.io/v1alpha3 types for DestinationRule
-- Generating networking.istio.io/v1beta1 types for DestinationRule
-- Generating networking.istio.io/v1alpha3 types for EnvoyFilter
-- Generating networking.istio.io/v1alpha3 types for Gateway
-- Generating networking.istio.io/v1beta1 types for Gateway
-- Generating networking.istio.io/v1beta1 types for ProxyConfig
-- Generating networking.istio.io/v1alpha3 types for ServiceEntry
-- Generating networking.istio.io/v1beta1 types for ServiceEntry
-- Generating networking.istio.io/v1alpha3 types for Sidecar
-- Generating networking.istio.io/v1beta1 types for Sidecar
-- Generating networking.istio.io/v1alpha3 types for VirtualService
-- Generating networking.istio.io/v1beta1 types for VirtualService
-- Generating networking.istio.io/v1alpha3 types for WorkloadEntry
-- Generating networking.istio.io/v1beta1 types for WorkloadEntry
-- Generating networking.istio.io/v1alpha3 types for WorkloadGroup
-- Generating networking.istio.io/v1beta1 types for WorkloadGroup
-- Generating security.istio.io/v1 types for AuthorizationPolicy
-- Generating security.istio.io/v1beta1 types for AuthorizationPolicy
-- Generating security.istio.io/v1beta1 types for PeerAuthentication
-- Generating security.istio.io/v1 types for RequestAuthentication
-- Generating security.istio.io/v1beta1 types for RequestAuthentication
-- Generating telemetry.istio.io/v1alpha1 types for Telemetry
-
-✅ Generated 23 files in the istio directory
-```
-
-Observe that the `kubernetes-fluent-client` has produced the TypeScript types within the `crds` directory. These types can now be utilized in the Pepr module.
-
-```typescript
-user@workstation$  cat crds/proxyconfig-v1beta1.ts
-// This file is auto-generated by kubernetes-fluent-client, do not edit manually
-
-import { GenericKind, RegisterKind } from "kubernetes-fluent-client";
-
-export class ProxyConfig extends GenericKind {
-    /**
-     * Provides configuration for individual workloads. See more details at:
-     * https://istio.io/docs/reference/config/networking/proxy-config.html
-     */
-    spec?:   Spec;
-    status?: { [key: string]: any };
-}
-
-/**
- * Provides configuration for individual workloads. See more details at:
- * https://istio.io/docs/reference/config/networking/proxy-config.html
- */
-export interface Spec {
-    /**
-     * The number of worker threads to run.
-     */
-    concurrency?: number;
-    /**
-     * Additional environment variables for the proxy.
-     */
-    environmentVariables?: { [key: string]: string };
-    /**
-     * Specifies the details of the proxy image.
-     */
-    image?: Image;
-    /**
-     * Optional.
-     */
-    selector?: Selector;
-}
-
-/**
- * Specifies the details of the proxy image.
- */
-export interface Image {
-    /**
-     * The image type of the image.
-     */
-    imageType?: string;
-}
-
-/**
- * Optional.
- */
-export interface Selector {
-    /**
-     * One or more labels that indicate a specific set of pods/VMs on which a policy should be
-     * applied.
-     */
-    matchLabels?: { [key: string]: string };
-}
-
-RegisterKind(ProxyConfig, {
-  group: "networking.istio.io",
-  version: "v1beta1",
-  kind: "ProxyConfig",
-});
-```
-
-## Using new types
-
-The generated types can be imported into Pepr directly, _there is no additional logic needed to make them to work_. 
-
-```typescript
-import { Capability, K8s, Log, a, kind } from "pepr";
-
-import { Gateway } from "../crds/gateway-v1beta1";
-import {
-  PurpleDestination,
-  VirtualService,
-} from "../crds/virtualservice-v1beta1";
-
-export const IstioVirtualService = new Capability({
-  name: "istio-virtual-service",
-  description: "Generate Istio VirtualService resources",
-});
-
-// Use the 'When' function to create a new action
-const { When, Store } = IstioVirtualService;
-
-// Define the configuration keys
-enum config {
-  Gateway = "uds/istio-gateway",
-  Host = "uds/istio-host",
-  Port = "uds/istio-port",
-  Domain = "uds/istio-domain",
-}
-
-// Define the valid gateway names
-const validGateway = ["admin", "tenant", "passthrough"];
-
-// Watch Gateways to get the HTTPS domain for each gateway
-When(Gateway)
-  .IsCreatedOrUpdated()
-  .WithLabel(config.Domain)
-  .Watch(vs => {
-    // Store the domain for the gateway
-    Store.setItem(vs.metadata.name, vs.metadata.labels[config.Domain]);
-  });
-```

package/website/content/en/docs/diagrams.txt

@@ -1,18 +0,0 @@
----
-title: Mermaid Diagram Samples
-description: Mermaid
----
-<!-- 
-In certain instances a markdown viewer may not display due to
-the '---' frontmatter block above. If you're one of those edge
-cases enclose the frontmatter at the top of this file entirely
-within a comment block just like this comment.
--->
-
-```mermaid
-graph TD
-  Start --> Need{"Hugo version >= 0.93.0"}
-  Need -- No --> Off["Set params.mermaid.enable = true"]
-  Off --> Author
-  Need -- Yes --> Author[Insert mermaid codeblock]
-```