@grepr/cli 1.2.0 → 1.3.0-94fe60c

package/build/dist/docs-index/5820530a-2cd4-49d1-9fa3-fdd2b02c263f.txt

@@ -1,248 +0,0 @@
----
-description: Learn how to create a Grepr pipeline, integrate the pipeline with your observability platform, such as Datadog, Splunk, or New Relic, and use that pipeline to lower your observability costs by dynamically reducing shipped log volumes.
----
-
-import { Callout } from 'nextra/components'
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# Tutorial: Build your first Grepr pipeline
-
-This tutorial is an end-to-end example that shows you how Grepr dynamically reduces the volume of shipped logs without losing data. It does this by walking you through an example that integrates Grepr with Datadog, creates a Grepr pipeline that processes log events forwarded from Datadog agents, and sends the resulting events to Datadog.
-
-In this tutorial, you:
-
-1. Verify that you can directly send log events from your local environment to Datadog.
-1. Configure a Grepr integration with Datadog.
-1. Configure a Grepr storage integration to store raw logs in the Grepr data lake.
-1. Create a Grepr pipeline that processes raw logs and sends the resulting processed events to Datadog.
-1. Use Docker to simulate multiple hosts sending log events to Grepr by running multiple Datadog agents in your local environment.
-1. Run the pipeline and view the output in the Grepr and Datadog UIs.
-
-<Callout>
-  - This tutorial uses Datadog as the observability tool. However, you can use this tutorial to create a pipeline that integrates with any Grepr-supported observability tool. For the complete list of supported observability vendors, see [Grepr supported integrations and regions](/integrations/support-matrix).
-  - To show you the most direct way to create a pipeline in the Grepr UI, this tutorial walks you through creating an end-to-end pipeline directly in the Grepr pipeline editor. However, to give you more control over configurations, the Grepr UI also includes separate interfaces to configure pipeline components such as integrations.
-  - This tutorial shows you how to send logs to Grepr using Datadog agents running in local Docker containers. However, if you have existing infrastructure forwarding logs to Datadog, you can use that infrastructure for this example. The Grepr Datadog integration also supports log collectors other than Datadog agents. To learn more about supported collectors, including configuration details, see [Configure Datadog connections for integration with Grepr](/integrations/datadog).
-</Callout>
-
-## Requirements
-
-To complete this tutorial, you must have:
-
-- A Grepr account and a login to your organization's Grepr UI. If you don't have a Grepr account, sign up at [https://app.grepr.ai/signup](https://app.grepr.ai/signup).
-- An organization identifier. A 3–31 character identifier containing only lowercase letters, numbers, and hyphens. If you don't have one, create an organization ID when you sign up for a Grepr account.
-- An account with an observability vendor supported by Grepr. This tutorial uses Datadog. If you don't have a Datadog account, you can sign up for a free trial at [www.datadoghq.com](https://www.datadoghq.com). For the complete list of supported observability vendors, see [Grepr supported integrations and regions](/integrations/support-matrix).
-- A Datadog API key for your account. You can retrieve this from your Datadog Organization Settings or copy it from the Agent Setup page instructions.
-- The Datadog site parameter that the Datadog agents should use. This parameter is determined by the Datadog site you selected. For example, if you select `US1`, then the value of the site parameter is `datadoghq.com`.
-- A Docker installation in your local environment. Docker is used to run the Datadog agents that send log events to Grepr.
-
-## Step 1: Verify that agents can send events to Datadog
-
-Before working through this tutorial, you should verify that Datadog agents running in your local environment can send log events directly to Datadog. In a terminal window, run the following command, replacing `DD_API_KEY_VALUE` with your Datadog API key and `DD_SITE_VALUE` with your Datadog site parameter. Optionally replace `DD_HOSTNAME` with a preferred hostname for testing. This value can be used in the Datadog UI to filter incoming log events:
-
-```bash copy
-docker run --rm --name dd-agent \
--e DD_API_KEY=DD_API_KEY_VALUE \
--e DD_SITE="datadoghq.com" \
--e DD_LOGS_ENABLED=true \
--e DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL=true \
--e DD_HOSTNAME=my-test-host \
--v /var/run/docker.sock:/var/run/docker.sock:ro \
--v /proc/:/host/proc/:ro \
--v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro \
-gcr.io/datadoghq/agent:latest
-```
-
-While this command runs, go to the Datadog UI, click **Logs**, and then click **Live Tail**. If everything's working correctly, you see log events arriving from the Datadog agent.
-
-![The Datadog Live Tail view illustrating logs being streamed to Datadog.](/images/tutorials/first-pipeline/datadogLiveTailScreenshot.png)
-
-To learn more about the Datadog Docker Agent, including details for the configuration options, see the [Datadog documentation](https://docs.datadoghq.com/containers/docker/).
-
-When you've finished testing, shut down the agent by running the following command in a separate terminal:
-
-```bash copy
-docker stop dd-agent
-```
-
-## Step 2: Create a Grepr pipeline to process log events
-
-A Grepr pipeline defines the steps to process log data. Pipelines you create in the Grepr UI implement a flow with the following steps to reduce the volume of log data sent to your observability platform:
-
-- Read logs from one or more sources. Sources use Grepr integrations, which connect Grepr to external systems such as observability vendors or cloud storage. This tutorial guides you through creating a source that uses a Grepr Datadog integration.
-- Filter log events at several stages in the pipeline.
-- Extract structured data from unstructured log messages or attributes using the Grepr Grok parser. See the [Grok parser](/transforms/grok) documentation.
-- Persist the raw logs into your Grepr data lake. To add a data lake in the pipeline editor, you must have a Grepr storage integration and a Grepr dataset configured.
-  - The storage integration is used to ensure retention of all data by storing raw logs in low-cost cloud storage. This tutorial uses a storage integration that uses a Grepr-hosted Amazon S3 bucket.
-  - The dataset defines a namespace in your storage specifying where the raw logs are stored.
-- Reduce the amount of log data to forward to your observability platform through the Log Reducer. To learn more about the Log Reducer, see [Optimizing logs with Grepr's intelligent aggregation](/grepr-platform/reduction).
-- Send the result of processing the logs to one or more sinks. Like sources, sinks use a configured Grepr integration.
-
-To create pipelines with more complex functionality, you can use the Grepr REST API. See the [Job creation API guide](/apis/job-creation-guide).
-
-To create a new pipeline:
-
-1. In the Grepr UI, click **Home** in the navigation menu, then click **Create Pipeline**.
-
-   ![Create a new pipeline in the Grepr UI.](/images/tutorials/first-pipeline/pipelines-page.png)
-
-1. In the **Create Pipeline** dialog, enter a name for your new pipeline.
-
-   ![Name the new pipeline in the Create Pipeline dialog.](/images/tutorials/first-pipeline/pipelines-create.png)
-
-1. Click **Create**.
-
-After clicking **Create**, the pipeline editor view appears. The left pane displays the flow for a log reduction pipeline. In the next step, you begin configuring the pipeline by adding a source.
-
-![The pipeline editor view.](/images/tutorials/first-pipeline/pipelines-editor.png)
-
-### Add a source for Datadog logs
-
-To add a source in the pipeline editor, you first configure a Grepr integration. To create an integration and add a source:
-
-1. Click **Continue** in the pipeline editor view.
-1. Click **Add integration**.
-1. In the **Add Observability Vendor** dialog:
-    - In the **Type** menu, select **Datadog**.
-    - In the **Name** field, enter a name for the integration.
-    - In the **Site** menu, select the parameter matching your Datadog site.
-    - In the **API Key** field, enter your Datadog API key.
-    - Leave the **Application Key** field empty.
-1. Click **Create**.
-
-   ![Add a new observability vendor integration in the Grepr UI.](/images/tutorials/first-pipeline/integrations-page-new-vendor.png)
-
-   After clicking **Create**, Grepr validates the API key with Datadog, creates the integration, and returns a success message. If any issues are found, an error message is returned instead.
-
-1. In the **Add source** dialog, select the Datadog integration you created in the previous step. A name for this source is automatically added for you.
-
-   ![Configure a source in the Grepr UI.](/images/tutorials/first-pipeline/pipelines-add-source.png)
-
-1. Click **Submit**.
-
-### Add a data lake
-
-To add a Grepr data lake to retain raw log data, you first configure a Grepr storage integration. To create a storage integration and add a data lake to your pipeline:
-
-1. Click **Data Lake** in the left pane, then click **Add**.
-1. In the **Add Data Lake** dialog:
-   - In the **Type** menu, select **Grepr-hosted**.
-   - In the **Name** field, enter a name for the integration.
-1. Click **Next**.
-
-   ![Add a new storage integration in the Grepr UI.](/images/tutorials/first-pipeline/integrations-page-new-grepr-storage.png)
-
-1. In the **Dataset Name** field, enter a name for the dataset to contain raw data. This can be any name you choose, but it should be descriptive.
-1. In the **Integration** menu, select the storage integration you created in the previous step.
-1. Click **Add**.
-
-To send the processed logs to Datadog, a sink is automatically added to your pipeline. Click **Sinks** in the left pane to view the sink. Under **Additional Tags / Attributes**, you can see automatically populated tags. These tags are appended to messages before they're sent to Datadog. Grepr recommends retaining these tags because they allow you to distinguish Grepr-processed logs from other logs.
-
-![View the automatically created sink in the Grepr UI.](/images/tutorials/first-pipeline/pipeline-sink.png)
-
-## Step 3: Create and start the pipeline
-
-Click **Create Pipeline** in the top bar, then click **Confirm** in the **Create pipeline** dialog. Your pipeline will shortly go from **Starting** to **Running**. When the pipeline reaches the **Running** state, it's ready to start processing logs. In the next step, you simulate sending log messages through your pipeline.
-
-## Step 4: Simulate multiple agents sending logs through Grepr
-
-1. Before sending log messages to your pipeline, make sure no Docker containers are running the Datadog agent. In a terminal, run the following command:
-
-   ```bash copy
-   docker stop dd-agent
-   ```
-
-1. To configure the Datadog agents to send logs to Grepr, you need the Grepr ingestion URL. To find the URL, click **Sources** in the left pane and copy the **Ingest URL** value.
-
-   ![Accessing the Grepr ingestion URL in the UI.](/images/integrations/ingestion-url-datadog.png)
-
-1. To start five agents to send logs through Grepr, run the following command, replacing `INGESTION_URL` with the Grepr ingestion URL you copied above, and `DD_API_KEY_VALUE` with your Datadog API key:
-
-   ```bash copy
-   for i in $(seq 1 5); do docker run -d --rm --name dd-agent-$i \
-   -e DD_API_KEY=DD_API_KEY_VALUE \
-   -e DD_SITE="datadoghq.com" \
-   -e DD_LOGS_ENABLED=true \
-   -e DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL=true \
-   -e DD_HOSTNAME=my-test-host-$i \
-   -v /var/run/docker.sock:/var/run/docker.sock:ro \
-   -v /proc/:/host/proc/:ro \
-   -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro \
-   -e DD_LOGS_CONFIG_LOGS_DD_URL=INGESTION_URL \
-   -e DD_LOGS_CONFIG_USE_HTTP="true" \
-   gcr.io/datadoghq/agent:latest; done
-   ```
-
-   This command starts five agents, each with a different hostname. There are two new environment variables added to the command: `DD_LOGS_CONFIG_LOGS_DD_URL` and `DD_LOGS_CONFIG_USE_HTTP`. The first variable provides the agents with the Grepr URL to send logs to, and the second variable tells the agents to use HTTPS instead of TCP when sending logs to Grepr.
-
-   <Callout type="info">
-     Before sending logs for ingestion, ensure there's at least one running pipeline that includes a Datadog source that matches the Datadog integration you created in Step 2. If a pipeline doesn't exist, the ingestion requests are not accepted.
-   </Callout>
-
-## View the results
-
-After the agents are running, to monitor log ingestion activity, go to the Grepr Pipelines UI and select **Overview**.
-
-![Pipeline overview page showing events arriving in the Grepr pipeline.](/images/tutorials/first-pipeline/pipeline-overview.png)
-
-To see the logs arriving to Datadog, go to the Datadog **Log Explorer**. To filter for only messages arriving from your test agents, enter `host:my-test-host*` in the **Filter your logs** text box.
-
-![The Datadog Log Explorer displaying processed logs.](/images/tutorials/first-pipeline/datadog-grepr-working.png)
-
-When you scroll through the logs in the Datadog **Log Explorer**, you can see that repeated log events are aggregated. This aggregation, which reduces the data volumes sent to Datadog, is the result of the Grepr Log Reducer. To learn more about the Log Reducer, see [Optimizing logs with Grepr's intelligent aggregation](/grepr-platform/reduction).
-
-## Cleaning up
-
-When you've finished the tutorial, you can stop the Datadog agents by running the following command in a terminal:
-
-```bash copy
-for i in $(seq 1 5); do docker stop dd-agent-$i; done
-```
-
-To stop the pipeline, go to the Grepr UI home page, click the **More options** icon (⋮) in the top-right corner of the pipeline card, select **Stop**, and then confirm that you would like to stop the pipeline.
-
-## Next steps
-
-To see an example of troubleshooting incidents with Grepr and Datadog, see the [troubleshooting tutorial](/tutorials/troubleshooting-example).
-
-<HiddenFAQ faqs={[
-  {
-    q: "What is a Grepr pipeline?",
-    a: "A Grepr pipeline is a configurable data processing workflow that reads logs from sources, applies filters and transformations, optionally stores raw logs in a data lake, reduces log volume using intelligent aggregation, and sends processed logs to sinks. Pipelines allow you to dynamically control log volumes without losing important data."
-  },
-  {
-    q: "How do I create my first Grepr pipeline?",
-    a: "To create your first pipeline, sign in to the Grepr UI, click 'Create Pipeline' on the Home page, enter a name, and click Create. The pipeline editor will open where you can add sources, configure integrations, set up storage, and create sinks. This tutorial walks through the complete process with a Datadog example."
-  },
-  {
-    q: "What observability platforms does Grepr support?",
-    a: "Grepr supports multiple observability vendors including Datadog, Splunk, New Relic, and others. For a complete list of supported platforms and regions, see the Grepr supported integrations and regions documentation."
-  },
-  {
-    q: "Do I need a Datadog account to follow this tutorial?",
-    a: "Yes, this tutorial uses Datadog as an example. However, you can follow the same steps with any Grepr-supported observability platform. If you don't have a Datadog account, sign up for a free trial at www.datadoghq.com or use your preferred observability platform."
-  },
-  {
-    q: "What is the Log Reducer and how does it work?",
-    a: "The Log Reducer is a Grepr component that intelligently aggregates repeated log events into summary messages, reducing the volume of logs sent to your observability platform. It identifies patterns in logs and uses placeholders for varying fields, allowing you to maintain visibility while reducing storage and processing costs."
-  },
-  {
-    q: "How do I configure a Datadog integration in Grepr?",
-    a: "To configure a Datadog integration, click 'Add integration' in the pipeline editor, select Datadog as the Type, enter a name for the integration, select your Datadog site from the menu, and enter your Datadog API key. Click Create and Grepr will validate the API key with Datadog."
-  },
-  {
-    q: "What is the Grepr data lake and why do I need it?",
-    a: "The Grepr data lake is a storage system that retains all raw log data in low-cost cloud storage using a Grepr-hosted Amazon S3 bucket. It ensures you don't lose any data while using the Log Reducer and allows you to backfill logs or perform historical analysis later."
-  },
-  {
-    q: "How do I monitor logs flowing through my pipeline?",
-    a: "You can monitor log ingestion in the Grepr Pipelines UI by selecting 'Overview' to see real-time event metrics. Additionally, go to your observability platform (Datadog, Splunk, etc.) to see the processed logs after reduction. In Datadog, filter using labels like 'host:my-test-host*' to see logs from your test agents."
-  },
-  {
-    q: "What happens to logs after the Log Reducer aggregates them?",
-    a: "After the Log Reducer aggregates logs into summary messages, they are sent to your observability platform sinks. The summary messages include metadata like repeat count, first/last timestamps, and a pattern ID, allowing you to trace back to raw logs stored in the data lake if needed."
-  },
-  {
-    q: "Can I test my pipeline changes before applying them to production?",
-    a: "Yes, Grepr provides a live edit feature that allows you to safely test changes to your pipeline without impacting production. Live edit creates a temporary copy of your pipeline and excludes sinks, preventing duplicate data from being sent to your observability platform."
-  }
-]} />

package/build/dist/docs-index/58a48874-7d23-451d-a75a-ce322384fa01.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/58a48874-7d23-451d-a75a-ce322384fa01.txt

@@ -1,35 +0,0 @@
-# NewRelic
-
-The payload containing integration data.
-
-**Type**: `object`
-
-## Properties
-
-- name: site (required)
-  type: string
-  description: New Relic API endpoint url base
-
-- name: accountId (optional)
-  type: string
-  description: Account Id for New Relic.
-
-- name: dashboardFreshnessWindow (optional)
-  type: string
-  description: The time window in which a dashboard must have been accessed to be considered active.
-
-- name: licenseKey (optional)
-  type: string
-  description: Masked license key for New Relic.
-
-- name: apiKey (optional)
-  type: string
-  description: Masked API key for New Relic.
-
-- name: exceptions (optional)
-  type: object
-  description: The imported exceptions from NewRelic. This is a map from the vendor resource ID to the exception.
-
-- name: useBabelFish (optional)
-  type: boolean
-  description: Whether to use Babel Fish for query processing

package/build/dist/docs-index/593f7012-a795-44dd-b3bb-ad998b14a4c9.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/593f7012-a795-44dd-b3bb-ad998b14a4c9.txt

@@ -1,3 +0,0 @@
-# MatrixData
-
-**Type**: `object`

package/build/dist/docs-index/5985999a-f35d-4681-947b-4c3953c05020.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/5985999a-f35d-4681-947b-4c3953c05020.txt

@@ -1,44 +0,0 @@
-# ReadSplunk
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-  description: Name of the integration.
-
-- name: version (required)
-  type: integer
-  description: Version of the integration. Should be increased by one for every new update in order for the write to succeed. Otherwise, a '409 Conflict' will be returned.
-
-- name: payload (required)
-  type: `Splunk`
-
-- name: teamIds (optional)
-  type: array of string
-  description: The team IDs that this integration is associated with.
-
-- name: id (required)
-  type: string
-  description: The integration id
-
-- name: organizationId (required)
-  type: string
-  description: Organization ID of the integration.
-
-- name: jobIds (required)
-  type: array of string
-  description: List of job IDs associated with the integration.
-
-- name: createdAt (required)
-  type: string
-  description: Timestamp when the integration was created.
-
-- name: updatedAt (required)
-  type: string
-  description: Timestamp when the integration was last updated.
-
-- name: type (required)
-  type: enum: `splunk`
-  description: The type of the integration. This is used to determine the payload type.

package/build/dist/docs-index/59c83412-f686-49a3-8a20-e28f945808dd.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/59c83412-f686-49a3-8a20-e28f945808dd.txt

@@ -1,25 +0,0 @@
-# Get dataset by ID
-
-**GET** `/v1/datasets/{id}`
-
-**Operation ID**: `getDatasetById`
-**Summary**: Get dataset by ID
-Get a dataset by its ID.
-
-## Tags
-- Datasets
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Responses
-
-### 200
-
-The list of datasets.
-
-- **Content-Type**: `application/json` / `DatasetRead`
-### 404
-
-Dataset not found.

package/build/dist/docs-index/5a114e9a-e43b-4ff7-ac4b-94a6396fd23f.json

@@ -1 +0,0 @@
-{"docType":"doc"}

package/build/dist/docs-index/5a114e9a-e43b-4ff7-ac4b-94a6396fd23f.txt

@@ -1,141 +0,0 @@
----
-description: A reference for the permission types in the Grepr platform, and which permissions are assigned to different roles.
----
-
-import { Callout } from 'nextra/components'
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# Permissions in the Grepr platform
-
-This page is a reference to the permissions available in the Grepr platform. These permissions are assigned to users based on the user's role:
-
-- Organization-level roles: Admin and Member
-- Team-level roles: Leader and Member
-
-A user can be assigned both an organization-level role and a team-level role. For example, an organization Member can also be a team Leader, giving them view access organization-wide and edit access to their team's resources.
-
- You can also create custom roles with a specific subset of Grepr platform permissions. To learn more about roles, including custom roles, see [Manage users in the Grepr platform](/admin/manage-users).
-
-At both the organization and team levels, there are two types of permissions:
-
-- View: Grants read-only access to specified resources.
-- Edit: Grants edit permissions over specified resources, including creating, editing, and deleting those resources.
-
-Resources in the Grepr platform include your organization, vendor, and storage integrations, datasets, templates, users, teams, and jobs.
-
-The following sections provide more details on permissions in the Grepr platform and the permissions for each role type.
-
-## Available permissions in the Grepr platform
-
-This table lists all available permissions for organization and team-level roles:
-
-| Permission | Resource              | Scope                |
-| :--------- | :-------------------- | :------------------- |
-| Edit       | Organization settings | Organization         |
-| View       | Organization settings | Organization or Team |
-| Edit       | Integrations          | Organization or Team |
-| View       | Integrations          | Organization or Team |
-| Edit       | Jobs                  | Organization or Team |
-| View       | Jobs                  | Organization or Team |
-| Edit       | Users                 | Organization         |
-| View       | Users                 | Organization or Team |
-| Edit       | Teams                 | Organization or Team |
-| View       | Teams                 | Organization or Team |
-| Edit       | Templates             | Organization or Team |
-| View       | Templates             | Organization or Team |
-| Edit       | Datasets              | Organization or Team |
-| View       | Datasets              | Organization or Team |
-
-## Permissions by role
-
-The following are the permissions granted to each role type in the Grepr platform:
-
-- Organization Admins have full control over all resources in the organization, including all team-scoped resources.
-- Organization Members have view-only permissions to all resources in the organization.
-- Team Leaders have edit permissions for all resources scoped to their specific team or teams. This includes permissions to create and edit jobs, integrations, templates, and datasets assigned to the team. Team Leaders can also view all organization resources, but only edit resources scoped to their team or teams.
-- Team Leaders have edit permissions for all resources scoped to their specific team or teams. This includes permissions to create and edit jobs, integrations, templates, and datasets assigned to the team. Team Leaders can also view all organization resources but only edit resources scoped to their team or teams.
- - Team Members have view-only permissions to resources scoped to their specific team or teams. A Member can view resources assigned to the team, run backfill jobs, and query logs, but does not have permission to create or edit resources, such as jobs, integrations, templates, or datasets, assigned to the team.
-- Teams can be granted access to resources, such as integrations, datasets, or templates, scoped at the organization level. When a team is granted access to a resource, team Leaders have edit permissions on the resource, and team Members have view-only permissions. However, to create or edit a job, such as a pipeline, a team Leader must have view permissions on all the integrations and datasets used by the job. For example, if a job is assigned to the `DevOps` team, but the team hasn't been granted access to an integration used in the job, a `DevOps` team Leader cannot edit or run the job.
-- To create a dataset, you must have edit permission on the integration the dataset belongs to.
-
-For each resource in the Grepr platform, this table shows the specific permissions granted to each role type at both the organization and team levels:
-
- | Permission | Resource              | Access Scope  | Organization Admin | Organization Member | Team Leader | Team Member |
- | :--------- | :-------------------- | :------------ | :----------------- | :------------------ | :---------- | :---------- |
- | View       | Organization Settings | Organization  | ✅                 | ✅                 | ✅          | ✅          |
- | Edit       | Organization Settings | Organization  | ✅                 | ❌                 | ❌          | ❌          |
- | View       | Users                 | Organization  | ✅                 | ✅                 | ✅          | ❌          |
- | Edit       | Users                 | Organization  | ✅                 | ❌                 | ❌          | ❌          |
- | View       | Teams                 | Organization  | ✅                 | ✅                 | ✅          | ❌          |
- | Edit       | Teams                 | Organization  | ✅                 | ❌                 | ❌          | ❌          |
- | View       | Integrations          | Organization  | ✅                 | ✅                 | ❌          | ❌          |
- | Edit       | Integrations          | Organization  | ✅                 | ❌                 | ❌          | ❌          |
- | View       | Datasets              | Organization  | ✅                 | ✅                 | ❌          | ❌          |
- | Edit       | Datasets              | Organization  | ✅                 | ❌                 | ❌          | ❌          |
- | View       | Jobs                  | Organization  | ✅                 | ✅                 | ❌          | ❌          |
- | Edit       | Jobs                  | Organization  | ✅                 | ❌                 | ❌          | ❌          |
- | View       | Templates             | Organization  | ✅                 | ✅                 | ✅          | ❌          |
- | Edit       | Templates             | Organization  | ✅                 | ❌                 | ❌          | ❌          |
- | View       | Teams                 | Team          | ✅                 | ✅                 | ✅          | ✅          |
- | Edit       | Teams                 | Team          | ✅                 | ❌                 | ✅          | ❌          |
- | View       | Integrations          | Team          | ✅                 | ✅                 | ✅          | ✅          |
- | Edit       | Integrations          | Team          | ✅                 | ❌                 | ✅          | ❌          |
- | View       | Datasets              | Team          | ✅                 | ✅                 | ✅          | ✅          |
- | Edit       | Datasets              | Team          | ✅                 | ❌                 | ✅          | ❌          |
- | View       | Jobs                  | Team          | ✅                 | ✅                 | ✅          | ✅          |
- | Edit       | Jobs                  | Team          | ✅                 | ❌                 | ✅          | ❌          |
- | View       | Templates             | Team          | ✅                 | ✅                 | ✅          | ✅          |
- | Edit       | Templates             | Team          | ✅                 | ❌                 | ✅          | ❌          |
-
-## Organization roles vs. team roles
-
-This table describes the difference between organization-level and team-level roles. Users can have both types of roles:
-
-|           | Organization roles                                     | Team roles                                  |
-| :-------- | :----------------------------------------------------- | :------------------------------------------ |
-| Scope     | Entire organization                                    | A specific team                             |
-| Types     | Admin, Member, or Custom Roles                         | Leader or Member                            |
-| Examples  | - Admin: Full access to all resources and settings.<br/>- Member: View organization resources.<br/>- Custom role, such as "Developer": Specific permissions like "view all jobs, edit templates". | - Leader: Manage team members, create team-scoped integrations.<br/>- Member: View team resources. |
-
-<HiddenFAQ faqs={[
-  {
-    q: "What are the two main permission types in Grepr?",
-    a: "The two main permission types are View (grants read-only access to specified resources) and Edit (grants permissions to create, edit, and delete specified resources). These permissions are assigned based on user roles at both organization and team levels."
-  },
-  {
-    q: "What are organization-level roles?",
-    a: "Organization-level roles control access across the entire organization. The two standard roles are Admin (full control over all resources) and Member (view-only access to all resources). You can also create custom roles with specific subsets of permissions tailored to your organization's needs."
-  },
-  {
-    q: "What are team-level roles?",
-    a: "Team-level roles control access to resources within a specific team. There are two team roles: Leader (edit permissions for team-scoped resources and view permissions for organization resources) and Member (view-only permissions for team resources). A user can be assigned to multiple teams with different roles."
-  },
-  {
-    q: "Can a user have both organization and team roles?",
-    a: "Yes, users can have both organization-level and team-level roles simultaneously. For example, a user can be an organization Member for organization-wide access while also being a Team Leader for a specific team, granting them edit access to that team's resources."
-  },
-  {
-    q: "What resources can be controlled with Grepr permissions?",
-    a: "Grepr permissions can control access to: organization settings, integrations (observability and storage), jobs, users, teams, templates, and datasets. Each resource can have view or edit permissions assigned at organization or team scope."
-  },
-  {
-    q: "What permissions does an Organization Admin have?",
-    a: "Organization Admins have full control over all resources in the organization, including all team-scoped resources. They can create, edit, and delete any resource, manage users, configure organization settings, and manage all integrations and datasets."
-  },
-  {
-    q: "What permissions does an Organization Member have?",
-    a: "Organization Members have view-only permissions to all resources in the organization. They can view integrations, datasets, jobs, users, and teams but cannot create, edit, or delete any resources at the organization level."
-  },
-  {
-    q: "What permissions does a Team Leader have?",
-    a: "Team Leaders have edit permissions for all resources scoped to their specific team(s), including creating and editing jobs, integrations, templates, and datasets. They can also view all organization resources but can only edit resources scoped to their team. Team Leaders can also manage team members."
-  },
-  {
-    q: "What permissions does a Team Member have?",
-    a: "Team Members have view-only permissions to resources scoped to their team. They can view and run backfill jobs, query logs, and view jobs, integrations, templates, and datasets assigned to the team, but cannot create or edit any resources."
-  },
-  {
-    q: "What is a custom role in Grepr?",
-    a: "Custom roles allow you to create roles with a specific subset of Grepr platform permissions tailored to your organization's needs. Instead of using standard roles, you can create custom roles like 'Developer' with permissions such as 'view all jobs' and 'edit templates' to match your team's responsibilities and access requirements."
-  }
-]} />

package/build/dist/docs-index/5b0058e6-f00f-4f9a-8162-ab840ef6d5f3.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/5b0058e6-f00f-4f9a-8162-ab840ef6d5f3.txt

@@ -1,17 +0,0 @@
-# TagWildcardNode
-
-**Type**: `object`
-
-## Properties
-
-- name: tagKey (required)
-  type: string
-  description: The tag key
-
-- name: wildcard (required)
-  type: string
-  description: This is a string including wildcards that is matched against the tag value.
-
-- name: type (required)
-  type: enum: `tag-wildcard-node`
-  description: A node that represents a tag wildcard in a parsed query.

package/build/dist/docs-index/5b076c25-5732-4f5d-aaf6-174d2b3d30f5.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/5b076c25-5732-4f5d-aaf6-174d2b3d30f5.txt

@@ -1,9 +0,0 @@
-# AverageAttributesMergeStrategy
-
-**Type**: `object`
-
-## Properties
-
-- name: type (required)
-  type: enum: `avg`
-  description: AverageAttributesMergeStrategy: Computes the average of numeric attribute values.

package/build/dist/docs-index/5b27464c-54fd-4706-9afd-17da1ea6238c.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/5b27464c-54fd-4706-9afd-17da1ea6238c.txt

@@ -1,15 +0,0 @@
-# Header
-
-A header with name and value
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-  description: Header name
-
-- name: value (required)
-  type: string
-  description: Header value

package/build/dist/docs-index/5bd02b8e-e812-4fe2-b742-f2d61690afef.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/5bd02b8e-e812-4fe2-b742-f2d61690afef.txt

@@ -1,20 +0,0 @@
-# deleteUser
-
-**DELETE** `/v1/users/{id}`
-
-**Operation ID**: `deleteUser`
-**Summary**: No summary provided.
-## Tags
-- Users
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Responses
-
-### default
-
-default response
-
-- **Content-Type**: `application/json` / No schema defined

package/build/dist/docs-index/5c377c17-156b-4bc0-894b-7720f1d839d2.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/5c377c17-156b-4bc0-894b-7720f1d839d2.txt

@@ -1,14 +0,0 @@
-# SqlIoStatement
-
-SQL statement that performs side effects like INSERT INTO
-
-**Type**: `object`
-
-## Properties
-
-- name: sqlQuery (required)
-  type: string
-  description: The SQL query to execute. Can reference tables created by previous statements by their tableName, as well as the 'traces' input table and available datasets.
-
-- name: materialized (optional)
-  type: boolean

package/build/dist/docs-index/5d59c3c3-4496-4d38-b2d3-95888b4002a1.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/5d59c3c3-4496-4d38-b2d3-95888b4002a1.txt

@@ -1,22 +0,0 @@
-# PipelineStatus
-
-Current operational status and health of the pipeline
-
-**Type**: `object`
-
-## Properties
-
-- name: health (optional)
-  type: enum: `HEALTHY`, `STABILIZING`, `UNHEALTHY`, `UNKNOWN`
-
-- name: message (optional)
-  type: string
-
-- name: isRolledBack (optional)
-  type: boolean
-
-- name: error (optional)
-  type: `ErrorDetails`
-
-- name: rolledBack (optional)
-  type: boolean