diff --git a/apps/openai-prompt/.gitignore b/apps/openai-prompt/.gitignore new file mode 100644 index 0000000..6dde684 --- /dev/null +++ b/apps/openai-prompt/.gitignore @@ -0,0 +1,28 @@ +logs +*.log +npm-debug.log* +yarn-debug.log* +yarn-error.log* +pnpm-debug.log* +lerna-debug.log* + +node_modules +dist +dist-ssr +*.local + +# Editor directories and files +.vscode/* +!.vscode/extensions.json +.idea +.DS_Store +*.suo +*.ntvs* +*.njsproj +*.sln +*.sw? + +# Environment variables +.env +.env.local +.env.*.local diff --git a/apps/openai-prompt/AGENTS.md b/apps/openai-prompt/AGENTS.md new file mode 100644 index 0000000..f1c471d --- /dev/null +++ b/apps/openai-prompt/AGENTS.md @@ -0,0 +1,49 @@ +# OpenAI Prompt + +This is a Datadog App scaffolded with `npm create @datadog/apps`. + +Datadog Apps are React + TypeScript applications bundled by Vite and embedded in the Datadog product experience. Frontend code runs in the browser. Backend functions live in `*.backend.*` files and execute through Datadog's managed runtime. + +## DRUIDS components + +This app uses the published `@datadog/druids` package. In scaffolded apps, import components from `@datadog/druids/[category]/[Component]`; do not import private web-ui paths like `@druids/ui/...`. + +- The scaffold imports `@datadog/druids/styles.css` at the React root and wraps the app in `DruidsEnvironmentWithThemeInput` (`@datadog/apps-frontend/druids/react`) below `DatadogAppProvider`. The environment follows the Datadog UI theme through the live `datadog.theme` input; `defaultThemePreference` in `src/main.tsx` only covers the first paint before the input claims. Keep that setup in place if you restructure the root. To keep DRUIDS' own cookie-based preference handling instead, render `DruidsEnvironment` from `@datadog/druids/layout/DruidsEnvironment`. +- Discover available components by browsing the installed package. Treat the `exports` map in `node_modules/@datadog/druids/package.json` as the source of truth for public entry points, and explore the corresponding category directories under `node_modules/@datadog/druids/dist` instead of relying on a hard-coded component list. +- After choosing an exported component, inspect its TypeScript definitions under `node_modules/@datadog/druids/dist/**/*.d.mts` before inventing props or imports. For icons, only use entry points that are present in the installed package. +- Start with the [DRUIDS docs](https://druids.datadoghq.com/), especially [Foundations](https://druids.datadoghq.com/foundations), [Spacing & Layout](https://druids.datadoghq.com/foundations/spacing-and-layout), [Typography](https://druids.datadoghq.com/foundations/typography), and [Components](https://druids.datadoghq.com/components). The docs cover the full internal DRUIDS library; the public `@datadog/druids` package exposes only a subset for Datadog Apps. +- Use the docs after confirming the local API to understand design intent, layout guidance, examples, and component selection tradeoffs. +- Prefer appropriate DRUIDS layout and typography components over ad hoc HTML wrappers or inline CSS. Use component props and design tokens for spacing, size, and variants. + +## Datadog App frontend embedding + +- The scaffold wraps the app in `DatadogAppProvider` from `@datadog/apps-frontend/embedding/react` at the React root. Keep that setup in place if you restructure the root; every `@datadog/apps-frontend` hook must be called below it. +- Read host-provided inputs with `useDatadogAppInput` from `@datadog/apps-frontend/inputs/react`, passing input schemas such as `datadogTheme` from `@datadog/apps-frontend/inputs/schema`. For details, read `docs/agents/runtime-context.md`. + +## Read relevant guides + +- For embedded Datadog app context, routing, navigation, browser storage, or parent-page constraints, read `docs/agents/runtime-context.md`. +- For writing backend functions in `*.backend.ts` or `*.backend.js` files, or for calling backend functions from frontend code, read `docs/agents/backend-functions.md`. +- For local development, auth, deploy, publish, `DD_APPS_PUBLISH`, or deploy troubleshooting, read `docs/agents/build-upload-auth.md`. +- For GitHub Actions CI/CD setup, read `docs/agents/cicd.md`. +- For choosing between DDSQL and Action Catalog, configuring Connections, or querying app datastores, read `docs/agents/data.md`. +- For triggering or polling a Workflow Automation workflow from a backend function, read `docs/agents/workflow-automation.md`. +- For upgrading `@datadog/vite-plugin` or `@datadog/action-catalog`, read `docs/agents/upgrading.md`. + +## General rules + +- Route every external network request through a backend function that calls the generic HTTP action from `@datadog/action-catalog/http/http`. Never call `fetch` or use Node.js networking APIs to contact external services directly, including from a backend function. +- Do not hardcode API keys, app keys, OAuth tokens, passwords, or third-party credentials. +- Set the `name` and `description` fields in `datadog-app.config.json` to concise, user-facing values that describe the app. +- Prefer the generated npm scripts in `package.json`; this scaffold uses npm. +- Never change `id` in `datadog-app.config.json`. It is this app's permanent identity, not the app's UUID from App Builder — changing it makes the next upload create a duplicate app. +- Before inventing package imports or component props, inspect installed package exports and TypeScript definitions. + +## Broader Datadog Apps guidance + +- For scaffolding a new app from scratch, use the Datadog Apps agent skill when it is available. +- Use Playwright when available for browser validation, including screenshots for visual design changes. +- Use the Datadog `pup` CLI (https://github.com/DataDog/pup) when available for Datadog API inspection and troubleshooting. +- Use Datadog MCP tools when available for Datadog-specific lookup, diagnostics, or API-backed workflows. + +Primary docs: https://docs.datadoghq.com/actions/datadog_apps/ diff --git a/apps/openai-prompt/CLAUDE.md b/apps/openai-prompt/CLAUDE.md new file mode 100644 index 0000000..43c994c --- /dev/null +++ b/apps/openai-prompt/CLAUDE.md @@ -0,0 +1 @@ +@AGENTS.md diff --git a/apps/openai-prompt/README.md b/apps/openai-prompt/README.md new file mode 100644 index 0000000..ddcaa37 --- /dev/null +++ b/apps/openai-prompt/README.md @@ -0,0 +1,16 @@ +# OpenAI Prompt + +A Datadog App that submits prompts to OpenAI through a Datadog-managed backend +function. + +## Configure OpenAI access + +1. In Datadog, create an HTTP connection for `api.openai.com`. +2. Configure the connection to send an `Authorization` header with the value + `Bearer `. +3. Copy the connection ID and replace + `replace-with-openai-http-connection-id` in `src/openai.backend.ts`. + +The connection ID must be a static value so Datadog can authorize it when the +app is uploaded. The API key remains in the Datadog connection and is never +included in frontend code. diff --git a/apps/openai-prompt/datadog-app.config.json b/apps/openai-prompt/datadog-app.config.json new file mode 100644 index 0000000..b2c7feb --- /dev/null +++ b/apps/openai-prompt/datadog-app.config.json @@ -0,0 +1,7 @@ +{ + "$schema": "https://unpkg.com/@datadog/create-apps/dist/datadog-app.config.schema.json", + "datadogSite": "datad0g.com", + "description": "Submit a prompt and view an OpenAI response from Datadog.", + "id": "383de73631814ff0cb1019eac250921b", + "name": "OpenAI Prompt" +} diff --git a/apps/openai-prompt/docs/agents/backend-functions.md b/apps/openai-prompt/docs/agents/backend-functions.md new file mode 100644 index 0000000..2e18f4f --- /dev/null +++ b/apps/openai-prompt/docs/agents/backend-functions.md @@ -0,0 +1,113 @@ +# Backend Functions + +Backend functions are Datadog-managed server-side functions. They do not ship to the browser. + +## File and export conventions + +- Backend files match `*.backend.ts`, `*.backend.js`, `*.backend.tsx`, or `*.backend.jsx`. +- Export named async functions from backend files. +- Frontend code imports backend functions like normal ES modules. +- The Datadog Vite plugin rewrites backend imports into proxy calls at build time. + +## Runtime behavior + +- Local development bundles backend functions through Vite middleware and executes them through Datadog preview infrastructure. +- Deployed apps call backend functions through the embedded Datadog runtime bridge. +- Backend functions do not run in the user's local Node.js process. + +## Backend helper library + +Datadog provides `@datadog/apps-backend`, a library of tools to make backend function development easier. Check it out when working on backend functions. + +## Security rules + +- Keep privileged Datadog API calls, third-party calls, and secret-dependent work in backend functions. +- Never hardcode API keys, app keys, OAuth tokens, passwords, private keys, or third-party credentials. +- Frontend code should not call Datadog APIs or other privileged services directly. +- Validate frontend inputs before using them in backend function calls. + +## External network requests + +All external network requests must use the generic HTTP action from `@datadog/action-catalog/http/http` in a backend function. Never call `fetch` or use Node.js networking APIs to contact an external service directly, including from a backend function. + +```ts +// src/getExternalData.backend.ts +import { request } from '@datadog/action-catalog/http/http'; + +export async function getExternalData() { + return request({ + inputs: { + verb: 'GET', + url: 'https://api.example.com/data', + responseParsing: 'json', + errorOnStatus: ['400-599'], + }, + }); +} +``` + +A connection is not required. Omit `connectionId` by default. Include it only when an existing Datadog HTTP connection contains authentication the request needs. Most users will not have one because a human must create it in the Datadog UI and copy its ID into the app. When a suitable connection does exist, pass its ID as `connectionId` alongside `inputs`. + +## Action Catalog + +Prefer `@datadog/action-catalog` for supported Datadog, cloud, SaaS, and HTTP workflows. Check the installed package exports before generating imports; do not invent subpaths. + +```ts +// src/listHosts.backend.ts +import { listHosts, type ListHostsResponse } from '@datadog/action-catalog/dd/hosts'; + +export async function getHosts(filter?: string): Promise { + return listHosts({ + inputs: { + filter: filter ?? '*', + count: 10, + include_hosts_metadata: true, + }, + }); +} +``` + +```tsx +// src/App.tsx +import { useQuery } from '@tanstack/react-query'; + +import { getHosts } from './listHosts.backend'; + +function HostCount() { + const hostsQuery = useQuery({ + queryKey: ['hosts', '*'], + queryFn: () => getHosts('*'), + }); + + if (hostsQuery.isLoading) { + return Loading hosts...; + } + + if (hostsQuery.isError) { + return Unable to load hosts.; + } + + return {hostsQuery.data?.host_list?.length ?? 0}; +} +``` + +Always wrap backend function proxies before passing them to React Query or +another framework callback. Do not use `queryFn: getHosts`: React Query calls +its callback with a context object containing an `AbortSignal`, and the +embedded app bridge cannot structured-clone that object for a backend +invocation. Pass only the cloneable arguments the backend function declares: + +```tsx +// Correct +queryFn: () => getHosts('*'), + +// Incorrect +queryFn: getHosts, +``` + +The generated app wraps React in `QueryClientProvider` in `src/main.tsx`. Prefer React Query for backend function calls that need loading, error, caching, retry, refetch, or deduplication behavior. + +## Broader data workflows + +- For choosing between DDSQL and Action Catalog, configuring Connections, or querying app datastores, read `docs/agents/data.md`. +- For triggering or polling a Workflow Automation workflow, read `docs/agents/workflow-automation.md`. diff --git a/apps/openai-prompt/docs/agents/build-upload-auth.md b/apps/openai-prompt/docs/agents/build-upload-auth.md new file mode 100644 index 0000000..2219d9d --- /dev/null +++ b/apps/openai-prompt/docs/agents/build-upload-auth.md @@ -0,0 +1,156 @@ +# Build, Auth, Deploy, And Publish + +This scaffold uses npm. Prefer the scripts in `package.json` over ad hoc commands. + +## Scripts + +- `npm run dev` — start the local Vite dev server. +- `npm run typecheck` — TypeScript check without emitting files. Use this for credential-free validation. +- `npm run lint` / `npm run lint:fix` — run ESLint. +- `npm run build` — production build (does not deploy by default). +- `npm run deploy` — build, upload, and publish the app live. +- `npm run publish` — publish the most recently uploaded version without rebuilding. + +## App identity (do not change) + +- `id` in `datadog-app.config.json` is this app's permanent identity. It was generated once when the project was scaffolded. +- Every upload updates the app that matches this identifier. **Never change it.** Changing it — including pasting the app's UUID from App Builder into it — makes the next upload create a brand-new duplicate app instead of updating the existing one. +- `id` is NOT the app UUID shown in App Builder. The UUID is assigned by Datadog; the id is a stable local key. Do not copy one into the other. + +## Auth + +Apps use **OAuth by default**. On first `npm run dev`, a browser window opens for Datadog login and the token is cached in the system keyring. No credentials needed in advance. + +**API key fallback** — use when OAuth isn't available (headless CI, restricted networks): + +1. Confirm `.env.local` is gitignored — the scaffold includes `*.local` in `.gitignore` by default. +2. Create `.env.local` at the project root with placeholders: + +``` +DD_API_KEY=REPLACE_WITH_YOUR_API_KEY +DD_APP_KEY=REPLACE_WITH_YOUR_APP_KEY +``` + +3. Open the file for editing — do not ask users to paste key values into the conversation: + +```bash +cursor .env.local 2>/dev/null || code .env.local 2>/dev/null || open .env.local +``` + +4. Direct the user to replace the placeholders. Keys are at: + - API keys: `https://app.datadoghq.com/organization-settings/api-keys` + - Application keys: `https://app.datadoghq.com/organization-settings/application-keys` — the key needs **two scopes**: **Actions API Access** and **Apps** + +Vite reads `.env.local` automatically once real values are in place. + +**`.env.local` not being picked up** — the scaffolded `vite.config.ts` reads credentials via `process.env`, which does not include `.env.local` at config evaluation time. Fix with Vite's `loadEnv`: + +```ts +import { defineConfig, loadEnv } from 'vite'; + +export default defineConfig(({ mode }) => { + const env = loadEnv(mode, process.cwd(), ''); + return { + plugins: [datadogVitePlugin({ auth: { apiKey: env.DD_API_KEY, appKey: env.DD_APP_KEY } })], + }; +}); +``` + +Restart the dev server after updating `vite.config.ts`. + +## Non-US1 site + +Set `datadogSite` in `datadog-app.config.json` so local dev and deploys target the right site: + +```json +{ "datadogSite": "" } +``` + +## Deploy + +Build, upload, and publish in one command: + +```bash +npm run deploy +``` + +With API keys (CI environments): + +```bash +export DD_API_KEY="" +export DD_APP_KEY="" +npm run deploy +``` + +A successful deploy prints a Datadog URL for the app. + +**Deploy without publishing** — upload as a draft without going live: + +```bash +npm run deploy -- --no-publish +# or +DD_APPS_PUBLISH=false npm run deploy +``` + +`DD_APPS_PUBLISH=false` is useful in CI when publishing is a separate step. + +## Publish + +Publish the most recently uploaded version without rebuilding: + +```bash +npm run publish +``` + +Publish a specific version by ID: + +```bash +npm run publish -- --version +``` + +When using `--version` without a cache file, set `DD_APPS_IDENTIFIER` to the app's identifier. + +**Older scaffolded projects** — if `deploy` and `publish` scripts are missing, add them to `package.json` (requires `@datadog/vite-plugin` >= 3.2.0): + +```json +{ "scripts": { "deploy": "datadog-apps deploy", "publish": "datadog-apps publish" } } +``` + +## Troubleshooting + +**401 / missing authentication token / credentials not configured** + +- OAuth: if the browser window didn't open, the environment may not support it. Fall back to API keys. +- API keys: verify `DD_API_KEY` and `DD_APP_KEY` are set and the application key has both **Actions API Access** and **Apps** scopes. +- Check `datadogSite` in `datadog-app.config.json` matches the credentials' Datadog site. + +**403 "you do not have access to this app" on upload** + +The application key needs both scopes enabled — not just one: + +1. **Actions API Access** — required for backend function execution. +2. **Apps** (or **App Builder**) — required for uploading and publishing. + +Go to `https://app.datadoghq.com/organization-settings/application-keys`, confirm both scopes, or create a new key with both. + +**Build succeeds but nothing deploys** + +- Use `npm run deploy`, not `npm run build`, when the intent is to deploy. +- Check whether `DD_APPS_PUBLISH` is set to `false` in the environment — the app uploads as a draft but does not go live. Unset the variable or run `npm run publish` separately. +- Confirm `dryRun` in `vite.config.ts` is not `true`. +- Confirm `DD_APPS_UPLOAD_ASSETS` is set — `npm run deploy` does this automatically. + +**Build fails with missing credentials** + +- Current scaffold versions may make `npm run build` exercise Datadog deploy behavior. +- Cache OAuth credentials first (`npm run dev`), or set `DD_API_KEY` and `DD_APP_KEY`. +- For credential-free validation, prefer `npm run typecheck`. + +**Node or scaffolding errors** + +- Check `package.json` `engines.node` for the supported Node.js versions. +- Use Volta, nvm, or fnm to switch versions. Prefer a current Node 22 release when debugging. + +**Datadog site mismatch** + +- Inspect `datadog-app.config.json` for the configured site and confirm CI uses the same value. diff --git a/apps/openai-prompt/docs/agents/cicd.md b/apps/openai-prompt/docs/agents/cicd.md new file mode 100644 index 0000000..72880bd --- /dev/null +++ b/apps/openai-prompt/docs/agents/cicd.md @@ -0,0 +1,42 @@ +# CI/CD + +## GitHub Actions + +Use `DataDog/apps-github-action` to deploy on pushes to the deployment branch. Keep `app-directory` aligned with the app's path in the repository. + +```yaml +name: Continuous Deployment +on: + push: + branches: + - main + +permissions: + contents: read + +jobs: + deploy-app: + name: Deploy Datadog App + runs-on: ubuntu-latest + permissions: + contents: read + id-token: write + + steps: + - name: Checkout + uses: actions/checkout@v6 + + - name: Setup Node.js + uses: actions/setup-node@v6 + + - name: Deploy + uses: DataDog/apps-github-action@v0.0.2 + with: + datadog-api-key: ${{ secrets.DATADOG_API_KEY }} + datadog-app-key: ${{ secrets.DATADOG_APP_KEY }} + app-directory: . +``` + +Store `DATADOG_API_KEY` and `DATADOG_APP_KEY` as [encrypted secrets](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions) in the repository or organization settings. The application key needs both **Actions API Access** and **Apps** scopes. + +For non-US1 organizations, configure the Datadog site in `datadog-app.config.json` (`datadogSite` field) and ensure CI and local config are aligned. diff --git a/apps/openai-prompt/docs/agents/data.md b/apps/openai-prompt/docs/agents/data.md new file mode 100644 index 0000000..e9cb8f6 --- /dev/null +++ b/apps/openai-prompt/docs/agents/data.md @@ -0,0 +1,63 @@ +# Data Access + +Backend functions have two primary data access paths: DDSQL and Action Catalog. + +## Choosing a path + +| Situation | Use | +| --- | --- | +| Read from Datadog-visible data (logs, metrics, hosts, spans, etc.) and need filtering, projection, joins, aggregation, or pagination | DDSQL | +| Mutation — create, update, delete, trigger, invoke, send | Action Catalog | +| Product workflow that maps to an existing typed action | Action Catalog | +| Simple single-record read where the typed action response is exactly what the UI needs | Action Catalog | +| External system or integration that is not DDSQL-visible | Action Catalog | +| Read from an app datastore | DDSQL (prefer for queries) or datastore actions (for simple reads/writes) | + +## DDSQL + +DDSQL-visible datasets include logs, APM spans, RUM events, hosts, containers, services, cloud inventory, audit trail, CI pipelines, and more. Check the [DDSQL Data Directory](https://docs.datadoghq.com/ddsql_reference/data_directory/) for the full list. + +Before writing queries: + +- Confirm the table name, columns, and types with a small bounded probe before writing app code. +- Verify the exact DDSQL execution API or action import against installed package exports — do not invent subpaths. +- Use fixed SQL templates. Do not accept raw frontend SQL or raw `ORDER BY` fields. +- Clamp limits and use `LIMIT` in all list queries. + +### App datastores + +Datastores are queryable via DDSQL. Confirm the datastore ID and column schema with a bounded probe first: + +```sql +SELECT key, summary, status +FROM dd.actions_datastores( + id => '', + columns => ARRAY ['key', 'summary', 'status'] +) AS ( + key VARCHAR, + summary VARCHAR, + status VARCHAR +) +WHERE status = 'Open' +ORDER BY key +LIMIT 100; +``` + +For writes and deletes, use datastore actions from `@datadog/action-catalog` directly. + +Public docs: [Datastores](https://docs.datadoghq.com/actions/datastores/), [DDSQL Reference](https://docs.datadoghq.com/ddsql_reference/) + +## Connections + +Connections are optional, reusable auth configuration for Action Catalog actions that need credentials (custom HTTP, integrations without a Datadog tile, etc.). + +- The generic HTTP action from `@datadog/action-catalog/http/http` does not require a connection. Omit `connectionId` by default. +- Include `connectionId` only when an existing HTTP connection contains authentication the request needs. +- Find or create connections at `https://app.datadoghq.com/actions/connections`. +- Copy the Connection ID from the connection details — treat it as configuration, not a secret. +- Do not ask users to paste API keys, passwords, OAuth secrets, or private keys into an AI conversation. +- Have a human create or update connections in the Datadog UI. Most users will not already have a suitable connection because it must be created manually and its ID copied into the app. + +Integrations such as GitHub, Jira, Slack, PagerDuty, and Statuspage may inherit credentials from their Datadog integration tile and may not need an explicit connection. + +Public docs: [Connections](https://docs.datadoghq.com/actions/connections/), [Action Catalog](https://docs.datadoghq.com/actions/action_interface/) diff --git a/apps/openai-prompt/docs/agents/runtime-context.md b/apps/openai-prompt/docs/agents/runtime-context.md new file mode 100644 index 0000000..93928c9 --- /dev/null +++ b/apps/openai-prompt/docs/agents/runtime-context.md @@ -0,0 +1,38 @@ +# Runtime Context + +Datadog Apps are embedded inside the Datadog UI. Treat this app as iframe-hosted browser code with Datadog-managed backend execution. + +## Iframe embedding + +- The app runs inside an iframe owned by the Datadog UI. +- The current App Builder iframe sandbox allows scripts, popups, popups escaping the sandbox, same-origin access, forms, and top navigation only by user activation. +- Do not assume app code can control, read, or directly navigate the parent Datadog page. +- Prefer hash-based routing for in-app routes. Avoid `BrowserRouter` and routers that depend on reliable top-level History API behavior. +- In-app links should use hash URLs such as `href="#/details"`. +- External URLs can open popups or top-level navigation only through browser-supported, user-initiated flows. +- Verify the current Datadog embedding sandbox before relying on a specific browser capability. Datadog controls the sandbox attributes and may change them. + +## Frontend helper library + +Datadog provides `@datadog/apps-frontend`, a library of React tools to make embedded frontend development easier. +The scaffold mounts `DatadogAppProvider` from `@datadog/apps-frontend/embedding/react` at the React root; +every `@datadog/apps-frontend` hook must be called below it. `useDatadogAppInput` from `@datadog/apps-frontend/inputs/react` reads typed inputs the host provides, with schemas such as `datadogTheme` in `@datadog/apps-frontend/inputs/schema`. +For DRUIDS apps, `DruidsEnvironmentWithThemeInput` from `@datadog/apps-frontend/druids/react` is a drop-in `DruidsEnvironment` that follows the live Datadog theme; the scaffold mounts it at the React root. +Check out this library for features, tools, utils and more + +## Storage and cookies + +- Browser storage is scoped to the app's origin and is not shared with the parent Datadog UI. +- Storage can differ between standalone local development and embedded runtime because modern browsers partition storage by top-level site and iframe origin. +- Third-party cookies are unreliable for durable app state. +- For durable server-side state, use backend functions and a Datadog-supported durable storage mechanism. + +## Backend call transport + +Frontend code imports backend functions like normal ES modules, but those imports are rewritten by the Datadog Vite plugin. The function body does not run in the browser. + +- In local dev, backend calls go through Vite middleware and Datadog preview infrastructure. +- In deployed apps, backend calls go through the Datadog iframe/runtime bridge. +- Do not build app logic that depends on backend functions running in the local Node.js process. + +For backend implementation details, read `backend-functions.md`. diff --git a/apps/openai-prompt/docs/agents/upgrading.md b/apps/openai-prompt/docs/agents/upgrading.md new file mode 100644 index 0000000..49d2a6d --- /dev/null +++ b/apps/openai-prompt/docs/agents/upgrading.md @@ -0,0 +1,70 @@ +# Upgrading + +## Primary packages + +- `@datadog/vite-plugin`: Vite integration for local development, build, and deploy. +- `@datadog/action-catalog`: typed Action Catalog client for backend functions. +- `@datadog/apps-backend`: Datadog-provided helpers for backend function development. +- `@datadog/apps-frontend`: Datadog-provided helpers and utils for apps, such as getting input context from the page! + +Preserve the existing package manager and lockfile style. + +## Before upgrading + +Check release notes before changing versions: + +```bash +npm view @datadog/vite-plugin version repository.url homepage +npm view @datadog/action-catalog version repository.url homepage +npm view @datadog/apps-backend version repository.url homepage +npm view @datadog/apps-frontend version repository.url homepage +``` + +Inspect the current app: + +```bash +npm outdated @datadog/vite-plugin @datadog/action-catalog @datadog/apps-backend @datadog/apps-frontend +npm ls @datadog/vite-plugin @datadog/action-catalog @datadog/apps-backend @datadog/apps-frontend +``` + +## Upgrade + +```bash +npm install @datadog/action-catalog@latest +npm install @datadog/apps-backend@latest +npm install @datadog/apps-frontend@latest +npm install -D @datadog/vite-plugin@latest +``` + +After upgrading, verify: + +- `datadog-app.config.json` app definition and configuration fields (`datadogSite`, `id`, `name`, `description`, `selfService`, `permissions`) and `vite.config.ts` Datadog plugin config. +- `package.json` scripts — check for new `deploy` and `publish` scripts added in `@datadog/vite-plugin` 3.2.0+. +- Backend function imports from `@datadog/action-catalog/...`. +- Frontend embedding and input imports from `@datadog/apps-frontend/...`. +- Project-local instructions in `AGENTS.md`. + +## Compare against a fresh scaffold + +To pull in changes from the latest scaffolder without guessing: + +```bash +tmp_dir="$(mktemp -d)" +npm create @datadog/apps@latest -- "$tmp_dir/base-app" --template vite-react -y --skip-post-scaffold +diff -ru "$tmp_dir/base-app/package.json" package.json +diff -ru "$tmp_dir/base-app/datadog-app.config.json" datadog-app.config.json +diff -ru "$tmp_dir/base-app/vite.config.ts" vite.config.ts +diff -ru "$tmp_dir/base-app/src" src +``` + +Port only the specific changes needed. Do not replace the app wholesale. + +**Preserve your existing `id`** — the fresh scaffold generates a new random `id` in `datadog-app.config.json`. Do not copy it into your project; keep your existing `id` to avoid creating a duplicate app on the next upload. + +## Verify + +```bash +npm run typecheck +npm run lint +npm run build +``` diff --git a/apps/openai-prompt/docs/agents/workflow-automation.md b/apps/openai-prompt/docs/agents/workflow-automation.md new file mode 100644 index 0000000..2ec9bcd --- /dev/null +++ b/apps/openai-prompt/docs/agents/workflow-automation.md @@ -0,0 +1,150 @@ +# Workflow Automation + +Use this when a backend function needs to trigger a Datadog Workflow Automation workflow and poll for the result. + +## Requirements + +- Use a backend function, not frontend code. Backend functions can call `@datadog/action-catalog`. +- Use the generic HTTP action from `@datadog/action-catalog/http/http`. +- The HTTP action requires a Connection ID for an HTTP connection configured in your Datadog org. Find or create one at `https://app.datadoghq.com/actions/connections`. +- The target workflow must be published and must include an API trigger (`apiTrigger` in the workflow spec). +- Workflow inputs must match the workflow input schema exactly. + +## Inspect the workflow first + +Before wiring an app to a workflow, confirm its published shape: + +```bash +workflow_id="" +curl -sS --fail-with-body \ + "https://api.datadoghq.com/api/v2/workflows/${workflow_id}" \ + -H "DD-API-KEY: ${DD_API_KEY}" \ + -H "DD-APPLICATION-KEY: ${DD_APP_KEY}" \ + -H "Accept: application/json" \ +| jq "{ + id: .data.id, + name: .data.attributes.name, + published: .data.attributes.published, + inputSchema: .data.attributes.spec.inputSchema, + outputSchema: .data.attributes.spec.outputSchema, + hasApiTrigger: any(.data.attributes.spec.triggers[]?; has(\"apiTrigger\")) + }" +``` + +Confirm `published` is `true`, `hasApiTrigger` is `true`, and `inputSchema.parameters` matches the inputs the app will send. + +## Trigger and poll pattern + +Inputs go under `meta.payload`. Replace `YOUR_HTTP_CONNECTION_ID` with the ID from your Datadog org. + +```ts +import { request } from '@datadog/action-catalog/http/http'; + +const DATADOG_HTTP_CONNECTION_ID = ''; +const DATADOG_API_BASE_URL = 'https://api.datadoghq.com'; +const DEFAULT_POLL_TIMEOUT_MS = 120_000; +const INITIAL_POLL_DELAY_MS = 250; +const POLL_DELAY_MULTIPLIER = 1.05; + +const jsonHeaders = [ + { key: 'Accept', value: ['application/json'] }, + { key: 'Content-Type', value: ['application/json'] }, +]; + +type WorkflowInstanceResponse = { + data?: { + id?: string; + attributes?: { + endTimestamp?: string | null; + outputs?: unknown; + instanceStatus?: { detailsKind?: string; displayName?: string }; + }; + }; +}; + +type WorkflowRunResult = { + instanceId?: string; + statusKind?: string; + displayStatus?: string; + outputs?: unknown; + body: unknown; +}; + +function workflowInstancesUrl(workflowId: string) { + return `${DATADOG_API_BASE_URL}/api/v2/workflows/${workflowId}/instances`; +} + +function isRunningStatus(statusKind?: string) { + return !statusKind || statusKind === 'IN_PROGRESS'; +} + +function toRunResult(body: unknown): WorkflowRunResult { + const response = body as WorkflowInstanceResponse | undefined; + return { + instanceId: response?.data?.id, + statusKind: response?.data?.attributes?.instanceStatus?.detailsKind, + displayStatus: response?.data?.attributes?.instanceStatus?.displayName, + outputs: response?.data?.attributes?.outputs, + body, + }; +} + +export async function triggerWorkflow( + workflowId: string, + payload: Record, +): Promise { + const response = await request({ + connectionId: DATADOG_HTTP_CONNECTION_ID, + inputs: { + verb: 'POST', + url: workflowInstancesUrl(workflowId), + requestHeaders: jsonHeaders, + responseParsing: 'json', + errorOnStatus: ['400-599'], + body: JSON.stringify({ meta: { payload } }), + }, + }); + return toRunResult(response.body); +} + +export async function pollWorkflowInstance( + workflowId: string, + instanceId: string, + timeoutMs = DEFAULT_POLL_TIMEOUT_MS, +): Promise { + const expiresAt = Date.now() + timeoutMs; + let delay = INITIAL_POLL_DELAY_MS / POLL_DELAY_MULTIPLIER; + + while (Date.now() < expiresAt) { + delay *= POLL_DELAY_MULTIPLIER; + const jitter = delay * 0.4 * (Math.random() - 0.5); + await new Promise((resolve) => setTimeout(resolve, delay + jitter)); + + const response = await request({ + connectionId: DATADOG_HTTP_CONNECTION_ID, + inputs: { + verb: 'GET', + url: `${workflowInstancesUrl(workflowId)}/${instanceId}`, + requestHeaders: jsonHeaders, + responseParsing: 'json', + errorOnStatus: ['400-599'], + }, + }); + + const result = toRunResult(response.body); + if (!isRunningStatus(result.statusKind)) { + return result; + } + } + + throw new Error(`Workflow instance ${instanceId} did not finish in time`); +} +``` + +Treat `statusKind === "SUCCEEDED"` as success. All other terminal statuses (`INSTANCE_ERROR`, `STEP_ERROR`, `CANCELED`) are failures — return the full response body so the caller can inspect `errorDetail` and partial outputs. + +## Troubleshooting + +- `input parameter not in workflow input schema`: update `meta.payload` keys to match `inputSchema.parameters`. +- `Expected trigger type TRIGGER_TYPE_API not found`: add and publish an API trigger on the workflow. +- 401/403: confirm `DD_API_KEY` and `DD_APP_KEY` are set with Actions API Access, and the app site matches the API host. diff --git a/apps/openai-prompt/index.html b/apps/openai-prompt/index.html new file mode 100644 index 0000000..84eab34 --- /dev/null +++ b/apps/openai-prompt/index.html @@ -0,0 +1,15 @@ + + + + + + + OpenAI Prompt + + + +
+ + + + diff --git a/apps/openai-prompt/package.json b/apps/openai-prompt/package.json new file mode 100644 index 0000000..81e2f21 --- /dev/null +++ b/apps/openai-prompt/package.json @@ -0,0 +1,25 @@ +{ + "name": "openai-prompt", + "version": "0.0.1", + "private": true, + "scripts": { + "dev": "vite", + "build": "vite build", + "upload": "DD_APPS_UPLOAD_ASSETS=1 vite build", + "lint": "eslint . --report-unused-disable-directives --max-warnings 0", + "lint:fix": "eslint . --fix", + "preview": "vite preview", + "typecheck": "tsc --noEmit" + }, + "dependencies": { + "@datadog/action-catalog": "^0.0.7", + "@datadog/apps-frontend": "^0.0.5", + "@datadog/druids": "^0.0.7", + "@tanstack/react-query": "^5.101.4", + "react": "^18.3.1", + "react-dom": "^18.3.1" + }, + "optionalDependencies": { + "@napi-rs/keyring": "^1.3.0" + } +} diff --git a/apps/openai-prompt/public/favicon.ico b/apps/openai-prompt/public/favicon.ico new file mode 100644 index 0000000..e04da3e Binary files /dev/null and b/apps/openai-prompt/public/favicon.ico differ diff --git a/apps/openai-prompt/src/App.tsx b/apps/openai-prompt/src/App.tsx new file mode 100644 index 0000000..c6129c2 --- /dev/null +++ b/apps/openai-prompt/src/App.tsx @@ -0,0 +1,147 @@ +import { Button } from '@datadog/druids/form/Button'; +import { TextArea } from '@datadog/druids/form/TextArea'; +import { Grid } from '@datadog/druids/layout/Grid'; +import { GridItem } from '@datadog/druids/layout/GridItem'; +import { Spacing } from '@datadog/druids/layout/Spacing'; +import { MessageBox } from '@datadog/druids/misc/MessageBox'; +import { Text } from '@datadog/druids/typography/Text'; +import { useMutation } from '@tanstack/react-query'; +import { FormEvent, useState } from 'react'; + +import { submitPrompt } from './openai.backend'; + +function getErrorMessage(error: unknown): string { + return error instanceof Error + ? error.message + : 'The request could not be completed. Try again.'; +} + +function App() { + const [prompt, setPrompt] = useState(''); + const promptMutation = useMutation({ + mutationFn: () => submitPrompt(prompt), + }); + + const handleSubmit = (event: FormEvent) => { + event.preventDefault(); + if (!prompt.trim()) { + return; + } + promptMutation.mutate(); + }; + + return ( + + + + + Ask OpenAI + + + Send a prompt from Datadog and view the generated response. + Requests run through a Datadog backend function, so your + OpenAI credential stays in its HTTP connection. + + + + + + Create a Datadog HTTP connection for api.openai.com with an + Authorization header set to Bearer plus your OpenAI API key, + then set its ID in openai.backend.ts before uploading the + app. The credential stays in the connection. + + + + +
+ + + +