chore: import upstream snapshot with attribution
This commit is contained in:
wehub-resource-sync
@@ -0,0 +1,11 @@
|
||||
## Manually add your environment variables (optional)
|
||||
|
||||
If you have any environment variables in your tasks, be sure to add them in the dashboard so deployed code runs successfully. In Node.js, these environment variables are accessed in your code using `process.env.MY_ENV_VAR`.
|
||||
|
||||
In the sidebar select the "Environment Variables" page, then press the "New environment variable"
|
||||
button. 
|
||||
|
||||
You can add values for your local dev environment, staging and prod. 
|
||||
|
||||
You can also add environment variables in code by following the steps on the [Environment Variables page](/deploy-environment-variables#in-your-code).
|
||||
@@ -0,0 +1,31 @@
|
||||
<Tabs>
|
||||
<Tab title="Bundle everything">
|
||||
|
||||
Bundle all ESM packages so that you don't have to specifiy them manually like this:
|
||||
|
||||
```ts trigger.config.ts
|
||||
import type { TriggerConfig } from "@trigger.dev/sdk";
|
||||
|
||||
export const config: TriggerConfig = {
|
||||
//..other stuff
|
||||
dependenciesToBundle: [/.*/],
|
||||
};
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab title="Bundle individual packages">
|
||||
|
||||
Bundle individual packages using strings or regex like this:
|
||||
|
||||
```ts trigger.config.ts
|
||||
import type { TriggerConfig } from "@trigger.dev/sdk";
|
||||
|
||||
export const config: TriggerConfig = {
|
||||
//..other stuff
|
||||
//either regex or strings of package names
|
||||
dependenciesToBundle: [/@sindresorhus/, "escape-string-regexp"],
|
||||
};
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
@@ -0,0 +1,3 @@
|
||||
<ParamField body="Project path" type="[path]">
|
||||
The path to the project. Defaults to the current directory.
|
||||
</ParamField>
|
||||
@@ -0,0 +1,98 @@
|
||||
import ProjectPathArg from "/snippets/cli-args-project-path.mdx";
|
||||
import CommonOptions from "/snippets/cli-options-common.mdx";
|
||||
import ProjectRefOption from "/snippets/cli-options-project-ref.mdx";
|
||||
import EnvFileOption from "/snippets/cli-options-env-file.mdx";
|
||||
import ConfigFileOption from "/snippets/cli-options-config-file.mdx";
|
||||
import SkipUpdateCheckOption from "/snippets/cli-options-skip-update-check.mdx";
|
||||
import BranchOption from "/snippets/cli-options-branch.mdx";
|
||||
|
||||
Run the command like this:
|
||||
|
||||
<CodeGroup>
|
||||
|
||||
```bash npm
|
||||
npx trigger.dev@latest deploy
|
||||
```
|
||||
|
||||
```bash pnpm
|
||||
pnpm dlx trigger.dev@latest deploy
|
||||
```
|
||||
|
||||
```bash yarn
|
||||
yarn dlx trigger.dev@latest deploy
|
||||
```
|
||||
|
||||
</CodeGroup>
|
||||
|
||||
<Warning>
|
||||
This will fail in CI if any version mismatches are detected. Ensure everything runs locally first
|
||||
using the [dev](/cli-dev-commands) command and don't bypass the version checks!
|
||||
</Warning>
|
||||
|
||||
It performs a few steps to deploy:
|
||||
|
||||
1. Optionally updates packages when running locally.
|
||||
2. Compiles and bundles the code.
|
||||
3. Deploys the code to the Trigger.dev instance.
|
||||
4. Registers the tasks as a new version in the environment (prod by default).
|
||||
|
||||
## Deploying from CI
|
||||
|
||||
When deploying from CI/CD environments such as GitHub Actions, GitLab CI, or Jenkins, you need to authenticate non-interactively by setting the `TRIGGER_ACCESS_TOKEN` environment variable. Please see the [CI / GitHub Actions guide](/github-actions) for more information.
|
||||
|
||||
## Arguments
|
||||
|
||||
```
|
||||
npx trigger.dev@latest deploy [path]
|
||||
```
|
||||
|
||||
<ProjectPathArg />
|
||||
|
||||
## Options
|
||||
|
||||
<ConfigFileOption />
|
||||
|
||||
<ProjectRefOption />
|
||||
|
||||
<EnvFileOption />
|
||||
|
||||
<SkipUpdateCheckOption />
|
||||
|
||||
<ParamField body="Environment" type="--env | -e">
|
||||
Defaults to `prod` but you can specify `staging` or `preview`. If you specify `preview` we will
|
||||
try and automatically detect the branch name from git.
|
||||
</ParamField>
|
||||
|
||||
<BranchOption />
|
||||
|
||||
<ParamField body="Dry run" type="--dry-run">
|
||||
Create a deployable build but don't deploy it. Prints out the build path so you can inspect it.
|
||||
</ParamField>
|
||||
|
||||
<ParamField body="Skip promotion" type="--skip-promotion">
|
||||
Skips automatically promoting the newly deployed version to the "current" deploy.
|
||||
</ParamField>
|
||||
|
||||
<ParamField body="Skip syncing env vars" type="--skip-sync-env-vars">
|
||||
Turn off syncing environment variables with the Trigger.dev instance.
|
||||
</ParamField>
|
||||
|
||||
<ParamField body="Local build" type="--local-build">
|
||||
Force building the deployment image locally using your local Docker. This is automatic when self-hosting.
|
||||
</ParamField>
|
||||
|
||||
### Common options
|
||||
|
||||
These options are available on most commands.
|
||||
|
||||
<CommonOptions />
|
||||
|
||||
### Self-hosting
|
||||
|
||||
When [self-hosting](/self-hosting/overview), builds are performed locally by default. Once you've logged in to your self-hosted instance using the CLI, you can deploy with:
|
||||
|
||||
```bash
|
||||
npx trigger.dev@latest deploy
|
||||
```
|
||||
|
||||
For CI/CD environments, set `TRIGGER_ACCESS_TOKEN` and `TRIGGER_API_URL` environment variables. See the [GitHub Actions guide](/github-actions#self-hosting) for more details.
|
||||
@@ -0,0 +1,72 @@
|
||||
import ProjectPathArg from "/snippets/cli-args-project-path.mdx";
|
||||
import CommonOptions from "/snippets/cli-options-common.mdx";
|
||||
import ProjectRefOption from "/snippets/cli-options-project-ref.mdx";
|
||||
import EnvFileOption from "/snippets/cli-options-env-file.mdx";
|
||||
import ConfigFileOption from "/snippets/cli-options-config-file.mdx";
|
||||
import SkipUpdateCheckOption from "/snippets/cli-options-skip-update-check.mdx";
|
||||
|
||||
This runs a server on your machine that can execute Trigger.dev tasks:
|
||||
|
||||
<CodeGroup>
|
||||
|
||||
```bash npm
|
||||
npx trigger.dev@latest dev
|
||||
```
|
||||
|
||||
```bash pnpm
|
||||
pnpm dlx trigger.dev@latest dev
|
||||
```
|
||||
|
||||
```bash yarn
|
||||
yarn dlx trigger.dev@latest dev
|
||||
```
|
||||
|
||||
</CodeGroup>
|
||||
|
||||
It will first perform an update check to prevent version mismatches, failed deploys, and other errors. You will always be prompted first.
|
||||
|
||||
You will see in the terminal that the server is running and listening for tasks. When you run a task, you will see it in the terminal along with a link to view it in the dashboard.
|
||||
|
||||
It is worth noting that each task runs in a separate Node process. This means that if you have a long-running task, it will not block other tasks from running.
|
||||
|
||||
## Options
|
||||
|
||||
<ConfigFileOption />
|
||||
|
||||
<ProjectRefOption />
|
||||
|
||||
<EnvFileOption />
|
||||
|
||||
<SkipUpdateCheckOption />
|
||||
|
||||
<ParamField body="Analyze build output" type="--analyze">
|
||||
Analyzes the build output and displays detailed import timings. This is useful for debugging the
|
||||
start times for your runs which can be caused by importing lots of code or heavy packages.
|
||||
</ParamField>
|
||||
|
||||
### Common options
|
||||
|
||||
These options are available on most commands.
|
||||
|
||||
<CommonOptions />
|
||||
|
||||
## Concurrently running the terminal
|
||||
|
||||
Install the concurrently package as a dev dependency:
|
||||
|
||||
```ts
|
||||
concurrently --raw --kill-others npm:dev:remix npm:dev:trigger
|
||||
```
|
||||
|
||||
Then add something like this in your package.json scripts:
|
||||
|
||||
```json
|
||||
"scripts": {
|
||||
"dev": "concurrently --raw --kill-others npm:dev:*",
|
||||
"dev:trigger": "npx trigger.dev@latest dev",
|
||||
// Add your framework-specific dev script here, for example:
|
||||
// "dev:next": "next dev",
|
||||
// "dev:remix": "remix dev",
|
||||
//...
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,35 @@
|
||||
import CommonOptions from "/snippets/cli-options-common.mdx";
|
||||
|
||||
Run the command like this:
|
||||
|
||||
<CodeGroup>
|
||||
|
||||
```bash npm
|
||||
npx trigger.dev@latest promote [version]
|
||||
```
|
||||
|
||||
```bash pnpm
|
||||
pnpm dlx trigger.dev@latest promote [version]
|
||||
```
|
||||
|
||||
```bash yarn
|
||||
yarn dlx trigger.dev@latest promote [version]
|
||||
```
|
||||
|
||||
</CodeGroup>
|
||||
|
||||
## Arguments
|
||||
|
||||
```
|
||||
npx trigger.dev@latest promote [version]
|
||||
```
|
||||
|
||||
<ParamField body="Deployment version" type="[version]">
|
||||
The version to promote. This is the version that was previously deployed.
|
||||
</ParamField>
|
||||
|
||||
### Common options
|
||||
|
||||
These options are available on most commands.
|
||||
|
||||
<CommonOptions />
|
||||
@@ -0,0 +1,4 @@
|
||||
<ParamField body="Preview branch" type="--branch | -b">
|
||||
When using `--env preview` the branch is automatically detected from git. But you can manually
|
||||
specify it by using this option, e.g. `--branch my-branch` or `-b my-branch`.
|
||||
</ParamField>
|
||||
@@ -0,0 +1,20 @@
|
||||
import LogLevelOption from "/snippets/cli-options-log-level.mdx";
|
||||
import SkipTelemetryOption from "/snippets/cli-options-skip-telemetry.mdx";
|
||||
import HelpOption from "/snippets/cli-options-help.mdx";
|
||||
import VersionOption from "/snippets/cli-options-version.mdx";
|
||||
|
||||
<ParamField body="Login profile" type="--profile">
|
||||
The login profile to use. Defaults to "default".
|
||||
</ParamField>
|
||||
|
||||
<ParamField body="API URL" type="--api-url | -a">
|
||||
Override the default API URL. If not specified, it uses `https://api.trigger.dev`. This can also be set via the `TRIGGER_API_URL` environment variable.
|
||||
</ParamField>
|
||||
|
||||
<LogLevelOption />
|
||||
|
||||
<SkipTelemetryOption />
|
||||
|
||||
<HelpOption />
|
||||
|
||||
<VersionOption />
|
||||
@@ -0,0 +1,3 @@
|
||||
<ParamField body="Config file" type="--config | -c">
|
||||
The name of the config file found at the project path. Defaults to `trigger.config.ts`
|
||||
</ParamField>
|
||||
@@ -0,0 +1,4 @@
|
||||
<ParamField body="Env file" type="--env-file">
|
||||
Load environment variables from a file. This will only hydrate the `process.env` of the CLI
|
||||
process, not the tasks.
|
||||
</ParamField>
|
||||
@@ -0,0 +1,3 @@
|
||||
<ParamField body="Help" type="--help | -h">
|
||||
Shows the help information for the command.
|
||||
</ParamField>
|
||||
@@ -0,0 +1,3 @@
|
||||
<ParamField body="Log level" type="--log-level | -l">
|
||||
The CLI log level to use. Options are `debug`, `info`, `log`, `warn`, `error`, and `none`. This does not affect the log level of your trigger.dev tasks. Defaults to `log`.
|
||||
</ParamField>
|
||||
@@ -0,0 +1,3 @@
|
||||
<ParamField body="Project ref" type="--project-ref | -p">
|
||||
The project ref. Required if there is no config file.
|
||||
</ParamField>
|
||||
@@ -0,0 +1,3 @@
|
||||
<ParamField body="Skip telemetry" type="--skip-telemetry">
|
||||
Opt-out of sending telemetry data. This can also be done via the `TRIGGER_TELEMETRY_DISABLED` environment variable. Just set it to anything other than an empty string.
|
||||
</ParamField>
|
||||
@@ -0,0 +1,3 @@
|
||||
<ParamField body="Skip update check" type="--skip-update-check">
|
||||
Skip checking for `@trigger.dev` package updates.
|
||||
</ParamField>
|
||||
@@ -0,0 +1,3 @@
|
||||
<ParamField body="Version" type="--version | -v">
|
||||
Displays the version number of the CLI.
|
||||
</ParamField>
|
||||
@@ -0,0 +1,34 @@
|
||||
```ts /trigger/openai.ts
|
||||
import { task } from "@trigger.dev/sdk";
|
||||
import OpenAI from "openai";
|
||||
|
||||
const openai = new OpenAI({
|
||||
apiKey: process.env.OPENAI_API_KEY,
|
||||
});
|
||||
|
||||
export const openaiTask = task({
|
||||
id: "openai-task",
|
||||
//specifying retry options overrides the defaults defined in your trigger.config file
|
||||
retry: {
|
||||
maxAttempts: 10,
|
||||
factor: 1.8,
|
||||
minTimeoutInMs: 500,
|
||||
maxTimeoutInMs: 30_000,
|
||||
randomize: false,
|
||||
},
|
||||
run: async (payload: { prompt: string }) => {
|
||||
//if this fails, it will throw an error and retry
|
||||
const chatCompletion = await openai.chat.completions.create({
|
||||
messages: [{ role: "user", content: payload.prompt }],
|
||||
model: "gpt-3.5-turbo",
|
||||
});
|
||||
|
||||
if (chatCompletion.choices[0]?.message.content === undefined) {
|
||||
//sometimes OpenAI returns an empty response, let's retry by throwing an error
|
||||
throw new Error("OpenAI call failed");
|
||||
}
|
||||
|
||||
return chatCompletion.choices[0].message.content;
|
||||
},
|
||||
});
|
||||
```
|
||||
@@ -0,0 +1 @@
|
||||
<Note>This feature is coming soon. Stay up to date with progress on our [Roadmap](https://feedback.trigger.dev/roadmap).</Note>
|
||||
@@ -0,0 +1 @@
|
||||
<Note>This feature is in review. Stay up to date with progress and vote on its priority on our [Roadmap](https://feedback.trigger.dev/roadmap).</Note>
|
||||
@@ -0,0 +1 @@
|
||||
<Check>This feature has been planned. Stay up to date with progress on our [Roadmap](https://feedback.trigger.dev/roadmap).</Check>
|
||||
@@ -0,0 +1,8 @@
|
||||
### `Cannot find matching keyid`
|
||||
|
||||
This error occurs when using Node.js v22 with corepack, as it's not yet compatible with the latest package manager signatures. To fix this, either:
|
||||
|
||||
1. Downgrade to Node.js v20 (LTS), or
|
||||
2. Install corepack globally: `npm i -g corepack@latest`
|
||||
|
||||
The corepack bug and workaround are detailed in [this issue](https://github.com/npm/cli/issues/8075).
|
||||
@@ -0,0 +1,21 @@
|
||||
Debugging your task code in `dev` is supported via VS Code, without having to pass in any additional flags. Create a launch configuration in `.vscode/launch.json`:
|
||||
|
||||
```json launch.json
|
||||
{
|
||||
"version": "0.2.0",
|
||||
"configurations": [
|
||||
{
|
||||
"name": "Trigger.dev: Dev",
|
||||
"type": "node",
|
||||
"request": "launch",
|
||||
"cwd": "${workspaceFolder}",
|
||||
"runtimeExecutable": "npx",
|
||||
"runtimeArgs": ["trigger.dev@latest", "dev"],
|
||||
"skipFiles": ["<node_internals>/**"],
|
||||
"sourceMaps": true
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Then you can start debugging your tasks code by selecting the `Trigger.dev: Dev` configuration in the debug panel, and set breakpoints in your tasks code.
|
||||
@@ -0,0 +1,37 @@
|
||||
## Deploying your task to Trigger.dev
|
||||
|
||||
For this guide, we'll manually deploy your task by running the [CLI deploy command](/cli-deploy-commands) below. Other ways to deploy are listed in the next section.
|
||||
|
||||
<CodeGroup>
|
||||
|
||||
```bash npm
|
||||
npx trigger.dev@latest deploy
|
||||
```
|
||||
|
||||
```bash pnpm
|
||||
pnpm dlx trigger.dev@latest deploy
|
||||
```
|
||||
|
||||
```bash yarn
|
||||
yarn dlx trigger.dev@latest deploy
|
||||
```
|
||||
|
||||
</CodeGroup>
|
||||
|
||||
### Other ways to deploy
|
||||
|
||||
<Tabs>
|
||||
|
||||
<Tab title="GitHub Actions">
|
||||
|
||||
Use GitHub Actions to automatically deploy your tasks whenever new code is pushed and when the `trigger` directory has changes in it. Follow [this guide](/github-actions) to set up GitHub Actions.
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab title="Vercel Integration">
|
||||
|
||||
We're working on adding an official [Vercel integration](/vercel-integration) which you can follow the progress of [here](https://feedback.trigger.dev/p/vercel-integration-3).
|
||||
|
||||
</Tab>
|
||||
|
||||
</Tabs>
|
||||
@@ -0,0 +1,20 @@
|
||||
## Our library of examples, guides and projects
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Walkthrough guides" icon="book" href="/guides/introduction">
|
||||
Detailed guides for setting up Trigger.dev with popular frameworks and services, including
|
||||
Next.js, Remix, Supabase, Stripe and more.
|
||||
</Card>
|
||||
<Card title="Example tasks" icon="code" href="/guides/introduction#example-tasks">
|
||||
Task code you can copy and paste to use in your own projects, including OpenAI, Vercel AI SDK,
|
||||
Deepgram, FFmpeg, Puppeteer, Stripe, Supabase and more.
|
||||
</Card>
|
||||
<Card title="Webhook guides" icon="code" href="/guides/frameworks/webhooks-guides-overview">
|
||||
Learn how to trigger tasks from webhooks, including Next.js, Remix, Supabase and Stripe and
|
||||
more.
|
||||
</Card>
|
||||
<Card title="Example projects" icon="GitHub" href="/guides/introduction#example-projects">
|
||||
Full-stack projects demonstrating how to use Trigger.dev. Fork them in GitHub as a starting
|
||||
point for your own projects.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
@@ -0,0 +1,6 @@
|
||||
## Prerequisites
|
||||
|
||||
- Setup a project in {framework}
|
||||
- Ensure TypeScript is installed
|
||||
- [Create a Trigger.dev account](https://cloud.trigger.dev)
|
||||
- Create a new Trigger.dev project
|
||||
@@ -0,0 +1,3 @@
|
||||
## Local development
|
||||
|
||||
To test this example task locally, be sure to install any packages from the build extensions you added to your `trigger.config.ts` file to your local machine. In this case, you need to install {packages}.
|
||||
@@ -0,0 +1,223 @@
|
||||
<Accordion title="Copy paste this prompt in full" icon="sparkles">
|
||||
|
||||
```md
|
||||
|
||||
I would like you to help me migrate my v3 task code to v4. Here are the important differences:
|
||||
|
||||
We've deprecated the `@trigger.dev/sdk/v3` import path and moved to a new path:
|
||||
|
||||
// This is the old path
|
||||
import { task } from "@trigger.dev/sdk/v3";
|
||||
|
||||
// This is the new path, use this instead
|
||||
import { task } from "@trigger.dev/sdk";
|
||||
|
||||
We've renamed the `handleError` hook to `catchError`. Use this instead of `handleError`.
|
||||
|
||||
`init` was previously used to initialize data used in the run function. This is the old version:
|
||||
|
||||
import { task } from "@trigger.dev/sdk";
|
||||
|
||||
const myTask = task({
|
||||
init: async () => {
|
||||
return {
|
||||
myClient: new MyClient(),
|
||||
};
|
||||
},
|
||||
run: async (payload: any, { ctx, init }) => {
|
||||
const client = init.myClient;
|
||||
await client.doSomething();
|
||||
},
|
||||
});
|
||||
|
||||
This is the new version using middleware and locals:
|
||||
|
||||
import { task, locals, tasks } from "@trigger.dev/sdk";
|
||||
|
||||
// Create a local for your client
|
||||
const MyClientLocal = locals.create<MyClient>("myClient");
|
||||
|
||||
// Set up middleware to initialize the client
|
||||
tasks.middleware("my-client", async ({ next }) => {
|
||||
const client = new MyClient();
|
||||
locals.set(MyClientLocal, client);
|
||||
await next();
|
||||
});
|
||||
|
||||
// Helper function to get the client
|
||||
function getMyClient() {
|
||||
return locals.getOrThrow(MyClientLocal);
|
||||
}
|
||||
|
||||
const myTask = task({
|
||||
run: async (payload: any, { ctx }) => {
|
||||
const client = getMyClient();
|
||||
await client.doSomething();
|
||||
},
|
||||
});
|
||||
|
||||
We’ve deprecated the `toolTask` function. Use `schemaTask` plus AI SDK `tool()` with `execute: ai.toolExecute(task)` (the `ai.tool()` wrapper is deprecated). This is the old version:
|
||||
|
||||
import { toolTask, schemaTask } from "@trigger.dev/sdk";
|
||||
import { z } from "zod";
|
||||
import { generateText } from "ai";
|
||||
|
||||
const myToolTask = toolTask({
|
||||
id: "my-tool-task",
|
||||
run: async (payload: any, { ctx }) => {},
|
||||
});
|
||||
|
||||
export const myAiTask = schemaTask({
|
||||
id: "my-ai-task",
|
||||
schema: z.object({
|
||||
text: z.string(),
|
||||
}),
|
||||
run: async (payload, { ctx }) => {
|
||||
const { text } = await generateText({
|
||||
prompt: payload.text,
|
||||
model: openai("gpt-4o"),
|
||||
tools: {
|
||||
myToolTask,
|
||||
},
|
||||
});
|
||||
},
|
||||
});
|
||||
|
||||
This is the new version:
|
||||
|
||||
import { schemaTask } from "@trigger.dev/sdk";
|
||||
import { ai } from "@trigger.dev/sdk/ai";
|
||||
import { z } from "zod";
|
||||
import { generateText, tool } from "ai";
|
||||
import { openai } from "@ai-sdk/openai";
|
||||
|
||||
// Convert toolTask to schemaTask with a schema
|
||||
const myToolTask = schemaTask({
|
||||
id: "my-tool-task",
|
||||
schema: z.object({
|
||||
// Add appropriate schema for your tool's payload
|
||||
input: z.string(),
|
||||
}),
|
||||
run: async (payload, { ctx }) => {},
|
||||
});
|
||||
|
||||
const myTool = tool({
|
||||
description: myToolTask.description ?? "",
|
||||
inputSchema: myToolTask.schema!,
|
||||
execute: ai.toolExecute(myToolTask),
|
||||
});
|
||||
|
||||
export const myAiTask = schemaTask({
|
||||
id: "my-ai-task",
|
||||
schema: z.object({
|
||||
text: z.string(),
|
||||
}),
|
||||
run: async (payload, { ctx }) => {
|
||||
const { text } = await generateText({
|
||||
prompt: payload.text,
|
||||
model: openai("gpt-4o"),
|
||||
tools: {
|
||||
myTool,
|
||||
},
|
||||
});
|
||||
},
|
||||
});
|
||||
|
||||
We've made several breaking changes that require code updates:
|
||||
|
||||
**Queue changes**: Queues must now be defined ahead of time using the `queue` function. You can no longer create queues "on-demand" when triggering tasks. This is the old version:
|
||||
|
||||
|
||||
// Old v3 way - creating queue on-demand
|
||||
await myTask.trigger({ foo: "bar" }, { queue: { name: "my-queue", concurrencyLimit: 10 } });
|
||||
|
||||
|
||||
This is the new version:
|
||||
|
||||
|
||||
// New v4 way - define queue first
|
||||
import { queue, task } from "@trigger.dev/sdk";
|
||||
|
||||
const myQueue = queue({
|
||||
name: "my-queue",
|
||||
concurrencyLimit: 10,
|
||||
});
|
||||
|
||||
export const myTask = task({
|
||||
id: "my-task",
|
||||
queue: myQueue, // Set queue on task
|
||||
run: async (payload: any, { ctx }) => {},
|
||||
});
|
||||
|
||||
// Now trigger without queue options
|
||||
await myTask.trigger({ foo: "bar" });
|
||||
|
||||
// Or specify queue by name
|
||||
await myTask.trigger({ foo: "bar" }, { queue: "my-queue" });
|
||||
|
||||
|
||||
**Lifecycle hooks**: Function signatures have changed to use a single object parameter instead of separate parameters. Prefer `onStartAttempt` over the deprecated `onStart` when you need code to run before each attempt. This is the old version:
|
||||
|
||||
|
||||
// Old v3 way
|
||||
export const myTask = task({
|
||||
id: "my-task",
|
||||
onStart: (payload, { ctx }) => {},
|
||||
onSuccess: (payload, output, { ctx }) => {},
|
||||
onFailure: (payload, error, { ctx }) => {},
|
||||
catchError: (payload, { ctx, error, retry }) => {},
|
||||
run: async (payload, { ctx }) => {},
|
||||
});
|
||||
|
||||
|
||||
This is the new version:
|
||||
|
||||
|
||||
// New v4 way - single object parameter for hooks
|
||||
export const myTask = task({
|
||||
id: "my-task",
|
||||
onStartAttempt: ({ payload, ctx }) => {}, // prefer over deprecated onStart
|
||||
onSuccess: ({ payload, ctx, task, output }) => {},
|
||||
onFailure: ({ payload, ctx, task, error }) => {},
|
||||
catchError: ({ payload, ctx, task, error, retry, retryAt, retryDelayInMs }) => {},
|
||||
run: async (payload, { ctx }) => {}, // run function unchanged
|
||||
});
|
||||
|
||||
|
||||
**BatchTrigger changes**: The `batchTrigger` function no longer returns runs directly. This is the old version:
|
||||
|
||||
|
||||
// Old v3 way
|
||||
const batchHandle = await tasks.batchTrigger([
|
||||
[myTask, { foo: "bar" }],
|
||||
[myOtherTask, { baz: "qux" }],
|
||||
]);
|
||||
|
||||
console.log(batchHandle.runs); // Direct access
|
||||
|
||||
|
||||
This is the new version:
|
||||
|
||||
|
||||
// New v4 way
|
||||
const batchHandle = await tasks.batchTrigger([
|
||||
[myTask, { foo: "bar" }],
|
||||
[myOtherTask, { baz: "qux" }],
|
||||
]);
|
||||
|
||||
const batch = await batch.retrieve(batchHandle.batchId); // Use batch.retrieve()
|
||||
console.log(batch.runs);
|
||||
|
||||
|
||||
**triggerAndWait / batchTriggerAndWait**: In v4 these return a Result object, not the raw output. Use `if (result.ok) { ... result.output }` or call `.unwrap()` to get the output (throws if the run failed). Do not wrap `triggerAndWait` or `batchTriggerAndWait` in `Promise.all` — this is not supported.
|
||||
|
||||
|
||||
**Context (ctx) changes**: `ctx.attempt.id` and `ctx.attempt.status` have been removed; use `ctx.attempt.number` where needed. `ctx.task.exportName` has been removed.
|
||||
|
||||
|
||||
Can you help me convert the following code from v3 to v4? Please include the full converted code in the answer, do not truncate it anywhere.
|
||||
|
||||
```
|
||||
|
||||
</Accordion>
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
### Correctly passing event handlers to React components
|
||||
|
||||
An issue can sometimes arise when you try to pass a function directly to the `onClick` prop. This is because the function may require specific arguments or context that are not available when the event occurs. By wrapping the function call in an arrow function, you ensure that the handler is called with the correct context and any necessary arguments. For example:
|
||||
|
||||
This works:
|
||||
|
||||
```tsx
|
||||
<Button onClick={() => myTask()}>Trigger my task</Button>
|
||||
```
|
||||
|
||||
Whereas this does not work:
|
||||
|
||||
```tsx
|
||||
<Button onClick={myTask}>Trigger my task</Button>
|
||||
```
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
### Next.js build failing due to missing API key in GitHub CI
|
||||
|
||||
This issue occurs during the Next.js app build process on GitHub CI where the Trigger.dev SDK is expecting the TRIGGER_SECRET_KEY environment variable to be set at build time. Next.js attempts to compile routes and creates static pages, which can cause issues with SDKs that require runtime environment variables. The solution is to mark the relevant pages as dynamic to prevent Next.js from trying to make them static. You can do this by adding the following line to the route file:
|
||||
|
||||
```ts
|
||||
export const dynamic = "force-dynamic";
|
||||
```
|
||||
@@ -0,0 +1,23 @@
|
||||
Trigger.dev runs your tasks on specific Node.js versions:
|
||||
|
||||
### v3
|
||||
|
||||
- Node.js `21.7.3`
|
||||
|
||||
### v4
|
||||
|
||||
- Node.js `21.7.3` (default)
|
||||
- Node.js `22.16.0` (`node-22`)
|
||||
- Bun `1.3.3` (`bun`)
|
||||
|
||||
You can change the runtime by setting the `runtime` field in your `trigger.config.ts` file.
|
||||
|
||||
```ts
|
||||
import { defineConfig } from "@trigger.dev/sdk";
|
||||
|
||||
export default defineConfig({
|
||||
// "node", "node-22" or "bun"
|
||||
runtime: "node-22",
|
||||
project: "<your-project-ref>",
|
||||
});
|
||||
```
|
||||
@@ -0,0 +1,4 @@
|
||||
In the Trigger.dev Cloud we automatically pause execution of tasks when they are waiting for
|
||||
longer than a few seconds.
|
||||
|
||||
When triggering and waiting for subtasks, the parent is checkpointed and while waiting does not count towards compute usage. When waiting for a time period (`wait.for` or `wait.until`), if the wait is longer than 5 seconds we checkpoint and it does not count towards compute usage.
|
||||
@@ -0,0 +1,6 @@
|
||||
## Learn more about using Python with Trigger.dev
|
||||
|
||||
<Card title="Python build extension" icon="code" href="/config/extensions/pythonExtension">
|
||||
Learn how to use our built-in Python build extension to install dependencies and run your Python
|
||||
code.
|
||||
</Card>
|
||||
@@ -0,0 +1 @@
|
||||
The most common cause of hitting the API rate limit is if you're calling `trigger()` on a task in a loop, instead of doing this use `batchTrigger()` which will trigger multiple tasks in a single API call. You can have up to 1,000 tasks in a single batch trigger call with SDK 4.3.1+ (500 in prior versions).
|
||||
@@ -0,0 +1,54 @@
|
||||
## Examples
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card
|
||||
title="Claude Thinking Chatbot"
|
||||
icon="messages"
|
||||
href="/guides/example-projects/claude-thinking-chatbot"
|
||||
>
|
||||
A chatbot using the AI SDK that demonstrates Anthropic Claude 3.7's thinking capabilities through the Realtime API and
|
||||
react hooks.
|
||||
</Card>
|
||||
<Card
|
||||
title="Image Generation with fal.ai"
|
||||
icon="image"
|
||||
href="/guides/example-projects/realtime-fal-ai"
|
||||
>
|
||||
A Next.js app that uses the Realtime API and react hooks to create on-demand image generation
|
||||
through fal.ai's services.
|
||||
</Card>
|
||||
<Card
|
||||
title="Realtime CSV Importer"
|
||||
icon="file-csv"
|
||||
href="/guides/example-projects/realtime-csv-importer"
|
||||
>
|
||||
Upload CSV files and view the progress of the task being processed on the frontend live using
|
||||
the Realtime API.
|
||||
</Card>
|
||||
<Card
|
||||
title="Batch LLM Evaluator"
|
||||
icon="sparkles"
|
||||
href="/guides/example-projects/batch-llm-evaluator"
|
||||
>
|
||||
A Next.js app that uses the Realtime API and react hooks to evaluate language model responses on
|
||||
the frontend in real-time.
|
||||
</Card>
|
||||
|
||||
</CardGroup>
|
||||
|
||||
### Learn more
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="View all our guides & examples" icon="books" href="/guides">
|
||||
Guides, example projects and example tasks. Copy any of the code and use it in your own
|
||||
projects.
|
||||
</Card>
|
||||
<Card
|
||||
title="Example projects repo"
|
||||
icon="github"
|
||||
href="https://github.com/triggerdotdev/examples"
|
||||
>
|
||||
Star/Fork our examples repo to learn more about how to use Trigger.dev in full stack
|
||||
applications.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
@@ -0,0 +1,8 @@
|
||||
## Learn more about Trigger.dev Realtime
|
||||
|
||||
To learn more, take a look at the following resources:
|
||||
|
||||
- [Trigger.dev Realtime](/realtime) - learn more about how to subscribe to runs and get real-time updates
|
||||
- [Realtime streaming](/realtime/react-hooks/streams) - learn more about streaming data from your tasks
|
||||
- [Batch Triggering](/triggering#tasks-batchtrigger) - learn more about how to trigger tasks in batches
|
||||
- [React hooks](/realtime/react-hooks) - learn more about using React hooks to interact with the Trigger.dev API
|
||||
@@ -0,0 +1,108 @@
|
||||
<ParamField path="id" type="string" required>
|
||||
The run ID.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="taskIdentifier" type="string" required>
|
||||
The task identifier.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="payload" type="object" required>
|
||||
The input payload for the run.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="output" type="object">
|
||||
The output result of the run.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="createdAt" type="Date" required>
|
||||
Timestamp when the run was created.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="updatedAt" type="Date" required>
|
||||
Timestamp when the run was last updated.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="number" type="number" required>
|
||||
Sequential number assigned to the run.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="status" type="RunStatus" required>
|
||||
Current status of the run.
|
||||
|
||||
<Accordion title="RunStatus enum">
|
||||
|
||||
| Status | Description |
|
||||
| -------------------- | --------------------------------------------------------------------------------------------------------- |
|
||||
| `WAITING_FOR_DEPLOY` | Task hasn't been deployed yet but is waiting to be executed |
|
||||
| `QUEUED` | Run is waiting to be executed by a worker |
|
||||
| `EXECUTING` | Run is currently being executed by a worker |
|
||||
| `REATTEMPTING` | Run has failed and is waiting to be retried |
|
||||
| `FROZEN` | Run has been paused by the system, and will be resumed by the system |
|
||||
| `COMPLETED` | Run has been completed successfully |
|
||||
| `CANCELED` | Run has been canceled by the user |
|
||||
| `FAILED` | Run has been completed with errors |
|
||||
| `CRASHED` | Run has crashed and won't be retried, most likely the worker ran out of resources, e.g. memory or storage |
|
||||
| `INTERRUPTED` | Run was interrupted during execution, mostly this happens in development environments |
|
||||
| `SYSTEM_FAILURE` | Run has failed to complete, due to an error in the system |
|
||||
| `DELAYED` | Run has been scheduled to run at a specific time |
|
||||
| `EXPIRED` | Run has expired and won't be executed |
|
||||
| `TIMED_OUT` | Run has reached it's maxDuration and has been stopped |
|
||||
|
||||
</Accordion>
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="durationMs" type="number" required>
|
||||
Duration of the run in milliseconds.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="costInCents" type="number" required>
|
||||
Total cost of the run in cents.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="baseCostInCents" type="number" required>
|
||||
Base cost of the run in cents before any additional charges.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="tags" type="string[]" required>
|
||||
Array of tags associated with the run.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="idempotencyKey" type="string">
|
||||
Key used to ensure idempotent execution.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="expiredAt" type="Date">
|
||||
Timestamp when the run expired.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="ttl" type="string">
|
||||
Time-to-live duration for the run.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="finishedAt" type="Date">
|
||||
Timestamp when the run finished.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="startedAt" type="Date">
|
||||
Timestamp when the run started.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="delayedUntil" type="Date">
|
||||
Timestamp until which the run is delayed.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="queuedAt" type="Date">
|
||||
Timestamp when the run was queued.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="metadata" type="Record<string, DeserializedJson>">
|
||||
Additional metadata associated with the run.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="error" type="SerializedError">
|
||||
Error information if the run failed.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="isTest" type="boolean" required>
|
||||
Indicates whether this is a test run.
|
||||
</ParamField>
|
||||
@@ -0,0 +1,7 @@
|
||||
- **`isQueued`**: Returns `true` when the status is `QUEUED`, `PENDING_VERSION`, or `DELAYED`
|
||||
- **`isExecuting`**: Returns `true` when the status is `EXECUTING` or `DEQUEUED`. These count against your concurrency limits.
|
||||
- **`isWaiting`**: Returns `true` when the status is `WAITING`. These do not count against your concurrency limits.
|
||||
- **`isCompleted`**: Returns `true` when the status is any of the completed statuses
|
||||
- **`isCanceled`**: Returns `true` when the status is `CANCELED`
|
||||
- **`isFailed`**: Returns `true` when the status is any of the failed statuses
|
||||
- **`isSuccess`**: Returns `true` when the status is `COMPLETED`
|
||||
@@ -0,0 +1,20 @@
|
||||
<Tip>
|
||||
Instead of running your Next.js app and Trigger.dev dev server in separate terminals, you can run them concurrently. First, add these scripts to your `package.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"scripts": {
|
||||
"trigger:dev": "npx trigger.dev@latest dev",
|
||||
"dev": "npx concurrently --kill-others --names \"next,trigger\" --prefix-colors \"yellow,blue\" \"next dev\" \"npm run trigger:dev\""
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Then, in your terminal, you can start both servers with a single command:
|
||||
|
||||
```bash
|
||||
npm run dev
|
||||
```
|
||||
|
||||
This will run both your Next.js app and Trigger.dev dev server in the same terminal window, with color-coded output to distinguish between them.
|
||||
</Tip>
|
||||
@@ -0,0 +1,7 @@
|
||||
<Accordion title="How to increase these limits?">
|
||||
These are soft-limits and can be increased. Before we introduce paid plans in July you can request
|
||||
more [on Discord](https://trigger.dev/discord) or by [contacting us](https://trigger.dev/contact).
|
||||
If you increase these defaults you may have to subscribe to a paid plan when we introduce them.
|
||||
For more details on the v3 Cloud pricing see the [pricing
|
||||
details](https://trigger.dev/pricing).
|
||||
</Accordion>
|
||||
@@ -0,0 +1,23 @@
|
||||
<Step title="Run the CLI `dev` command">
|
||||
|
||||
The CLI `dev` command runs a server for your tasks. It watches for changes in your `/trigger` directory and communicates with the Trigger.dev platform to register your tasks, perform runs, and send data back and forth.
|
||||
|
||||
It can also update your `@trigger.dev/*` packages to prevent version mismatches and failed deploys. You will always be prompted first.
|
||||
|
||||
<CodeGroup>
|
||||
|
||||
```bash npm
|
||||
npx trigger.dev@latest dev
|
||||
```
|
||||
|
||||
```bash pnpm
|
||||
pnpm dlx trigger.dev@latest dev
|
||||
```
|
||||
|
||||
```bash yarn
|
||||
yarn dlx trigger.dev@latest dev
|
||||
```
|
||||
|
||||
</CodeGroup>
|
||||
|
||||
</Step>
|
||||
@@ -0,0 +1,39 @@
|
||||
<Step title="Run the CLI `init` command">
|
||||
|
||||
The easiest way to get started is to use the CLI. It will add Trigger.dev to your existing project, create a `/trigger` folder and give you an example task.
|
||||
|
||||
Run this command in the root of your project to get started:
|
||||
|
||||
<CodeGroup>
|
||||
|
||||
```bash npm
|
||||
npx trigger.dev@latest init
|
||||
```
|
||||
|
||||
```bash pnpm
|
||||
pnpm dlx trigger.dev@latest init
|
||||
```
|
||||
|
||||
```bash yarn
|
||||
yarn dlx trigger.dev@latest init
|
||||
```
|
||||
|
||||
</CodeGroup>
|
||||
|
||||
|
||||
It will do a few things:
|
||||
|
||||
<Tip title="MCP Server">
|
||||
Our [Trigger.dev MCP server](/mcp-introduction) gives your AI assistant direct access to Trigger.dev tools; search docs, trigger tasks, deploy projects, and monitor runs. We recommend installing it for the best developer experience.
|
||||
</Tip>
|
||||
|
||||
1. Ask if you want to install the [Trigger.dev MCP server](/mcp-introduction) for your AI assistant.
|
||||
2. Log you into the CLI if you're not already logged in.
|
||||
3. Ask you to select your project.
|
||||
4. Install the required SDK packages.
|
||||
5. Ask where you'd like to create the `/trigger` directory and create it with an example task.
|
||||
6. Create a `trigger.config.ts` file in the root of your project.
|
||||
|
||||
Install the "Hello World" example task when prompted. We'll use this task to test the setup.
|
||||
|
||||
</Step>
|
||||
@@ -0,0 +1,13 @@
|
||||
<Step title="Perform a test run using the dashboard">
|
||||
|
||||
The CLI `dev` command spits out various useful URLs. Right now we want to visit the Test page.
|
||||
|
||||
You should see our Example task in the list <Icon icon="circle-1" iconType="solid" size={20} color="F43F47" />, select it. Most tasks have a "payload" which you enter in the JSON editor <Icon icon="circle-2" iconType="solid" size={20} color="F43F47" />, but our example task doesn't need any input.
|
||||
|
||||
You can configure options on the run <Icon icon="circle-3" iconType="solid" size={20} color="F43F47" />, view recent payloads <Icon icon="circle-4" iconType="solid" size={20} color="F43F47" />, and create run templates <Icon icon="circle-5" iconType="solid" size={20} color="F43F47" />.
|
||||
|
||||
Press the "Run test" button <Icon icon="circle-6" iconType="solid" size={20} color="F43F47" />.
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
@@ -0,0 +1,11 @@
|
||||
<Step title="View your run">
|
||||
|
||||
Congratulations, you should see the run page which will live reload showing you the current state of the run.
|
||||
|
||||
|
||||
|
||||
If you go back to your terminal you'll see that the dev command also shows the task status and links to the run log.
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
@@ -0,0 +1,6 @@
|
||||
<Note>
|
||||
To learn more about how to properly configure Supabase auth for Trigger.dev tasks, please refer to
|
||||
our [Supabase Authentication guide](/guides/frameworks/supabase-authentication). It demonstrates
|
||||
how to use JWT authentication for user-specific operations or your service role key for
|
||||
admin-level access.
|
||||
</Note>
|
||||
@@ -0,0 +1,43 @@
|
||||
## Learn more about Supabase and Trigger.dev
|
||||
|
||||
### Full walkthrough guides from development to deployment
|
||||
|
||||
<CardGroup cols={1}>
|
||||
<Card
|
||||
title="Edge function hello world guide"
|
||||
icon="book"
|
||||
href="/guides/frameworks/supabase-edge-functions-basic"
|
||||
>
|
||||
Learn how to trigger a task from a Supabase edge function when a URL is visited.
|
||||
</Card>
|
||||
<Card
|
||||
title="Database webhooks guide"
|
||||
icon="book"
|
||||
href="/guides/frameworks/supabase-edge-functions-database-webhooks"
|
||||
>
|
||||
Learn how to trigger a task from a Supabase edge function when an event occurs in your database.
|
||||
</Card>
|
||||
<Card
|
||||
title="Supabase authentication guide"
|
||||
icon="book"
|
||||
href="/guides/frameworks/supabase-authentication"
|
||||
>
|
||||
Learn how to authenticate Supabase tasks using JWTs for Row Level Security (RLS) or service role
|
||||
keys for admin access.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### Task examples with code you can copy and paste
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card
|
||||
title="Supabase database operations"
|
||||
icon="bolt"
|
||||
href="/guides/examples/supabase-database-operations"
|
||||
>
|
||||
Run basic CRUD operations on a table in a Supabase database using Trigger.dev.
|
||||
</Card>
|
||||
<Card title="Supabase Storage upload" icon="bolt" href="/guides/examples/supabase-storage-upload">
|
||||
Download a video from a URL and upload it to Supabase Storage using S3.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
@@ -0,0 +1,36 @@
|
||||
<Step title="Optional step 1: create a new Supabase project">
|
||||
|
||||
<Info> If you already have a Supabase project on your local machine you can skip this step.</Info>
|
||||
|
||||
You can create a new project by running the following command in your terminal using the Supabase CLI:
|
||||
|
||||
```bash
|
||||
supabase init
|
||||
```
|
||||
|
||||
<Note>
|
||||
If you are using VS Code, ensure to answer 'y' when asked to generate VS Code settings for Deno,
|
||||
and install any recommended extensions.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Optional step 2: create a package.json file">
|
||||
|
||||
If your project does not already have `package.json` file (e.g. if you are using Deno), create it manually in your project's root folder.
|
||||
|
||||
<Info> If your project has a `package.json` file you can skip this step.</Info>
|
||||
|
||||
This is required for the Trigger.dev SDK to work correctly.
|
||||
|
||||
```ts package.json
|
||||
{
|
||||
"devDependencies": {
|
||||
"typescript": "^5.6.2"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<Note> Update your Typescript version to the latest version available. </Note>
|
||||
|
||||
</Step>
|
||||
@@ -0,0 +1,47 @@
|
||||
Run your Next.js app:
|
||||
|
||||
<CodeGroup>
|
||||
|
||||
```bash npm
|
||||
npm run dev
|
||||
```
|
||||
|
||||
```bash pnpm
|
||||
pnpm run dev
|
||||
```
|
||||
|
||||
```bash yarn
|
||||
yarn dev
|
||||
```
|
||||
|
||||
</CodeGroup>
|
||||
|
||||
Run the dev server from Step 2. of the [Initial Setup](/guides/frameworks/nextjs#initial-setup) section above if it's not already running:
|
||||
|
||||
<CodeGroup>
|
||||
|
||||
```bash npm
|
||||
npx trigger.dev@latest dev
|
||||
```
|
||||
|
||||
```bash pnpm
|
||||
pnpm dlx trigger.dev@latest dev
|
||||
```
|
||||
|
||||
```bash yarn
|
||||
yarn dlx trigger.dev@latest dev
|
||||
```
|
||||
|
||||
</CodeGroup>
|
||||
|
||||
Now visit the URL in your browser to trigger the task. Ensure the port number is the same as the one you're running your Next.js app on. For example, if you're running your Next.js app on port 3000, visit:
|
||||
|
||||
```bash
|
||||
http://localhost:3000/api/hello-world
|
||||
```
|
||||
|
||||
You should see the CLI log the task run with a link to view the logs in the dashboard.
|
||||
|
||||
|
||||
|
||||
Visit the [Trigger.dev dashboard](https://cloud.trigger.dev) to see your run.
|
||||
@@ -0,0 +1,47 @@
|
||||
Run your Remix app:
|
||||
|
||||
<CodeGroup>
|
||||
|
||||
```bash npm
|
||||
npm run dev
|
||||
```
|
||||
|
||||
```bash pnpm
|
||||
pnpm run dev
|
||||
```
|
||||
|
||||
```bash yarn
|
||||
yarn dev
|
||||
```
|
||||
|
||||
</CodeGroup>
|
||||
|
||||
Run the dev server from Step 2. of the [Initial Setup](/guides/frameworks/remix#initial-setup) section above if it's not already running:
|
||||
|
||||
<CodeGroup>
|
||||
|
||||
```bash npm
|
||||
npx trigger.dev@latest dev
|
||||
```
|
||||
|
||||
```bash pnpm
|
||||
pnpm dlx trigger.dev@latest dev
|
||||
```
|
||||
|
||||
```bash yarn
|
||||
yarn dlx trigger.dev@latest dev
|
||||
```
|
||||
|
||||
</CodeGroup>
|
||||
|
||||
Now visit the URL in your browser to trigger the task. Ensure the port number is the same as the one you're running your Remix app on. For example, if you're running your Remix app on port 3000, visit:
|
||||
|
||||
```bash
|
||||
http://localhost:3000/api/trigger
|
||||
```
|
||||
|
||||
You should see the CLI log the task run with a link to view the logs in the dashboard.
|
||||
|
||||
|
||||
|
||||
Visit the [Trigger.dev dashboard](https://cloud.trigger.dev) to see your run.
|
||||
@@ -0,0 +1,24 @@
|
||||
## Featured use cases
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card
|
||||
title="Data processing & ETL workflows"
|
||||
icon="database"
|
||||
href="/guides/use-cases/data-processing-etl"
|
||||
>
|
||||
Build complex data pipelines that process large datasets without timeouts.
|
||||
</Card>
|
||||
<Card title="Media processing workflows" icon="film" href="/guides/use-cases/media-processing">
|
||||
Batch process videos, images, audio, and documents with no execution time limits.
|
||||
</Card>
|
||||
<Card
|
||||
title="AI media generation workflows"
|
||||
icon="wand-magic-sparkles"
|
||||
href="/guides/use-cases/media-generation"
|
||||
>
|
||||
Generate images, videos, audio, documents and other media using AI models.
|
||||
</Card>
|
||||
<Card title="Marketing workflows" icon="bullhorn" href="/guides/use-cases/marketing">
|
||||
Build drip campaigns, create marketing content, and orchestrate multi-channel campaigns.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
@@ -0,0 +1,16 @@
|
||||
## Useful next steps
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Tasks overview" icon="diagram-subtask" href="/tasks/overview">
|
||||
Learn what tasks are and their options
|
||||
</Card>
|
||||
<Card title="Writing tasks" icon="pen-nib" href="/writing-tasks-introduction">
|
||||
Learn how to write your own tasks
|
||||
</Card>
|
||||
<Card title="Deploy using the CLI" icon="terminal" href="/cli-deploy-commands">
|
||||
Learn how to deploy your task manually using the CLI
|
||||
</Card>
|
||||
<Card title="Deploy using GitHub actions" icon="github" href="/github-actions">
|
||||
Learn how to deploy your task using GitHub actions
|
||||
</Card>
|
||||
</CardGroup>
|
||||
@@ -0,0 +1,47 @@
|
||||
## Learn more about Next.js and Trigger.dev
|
||||
|
||||
### Walk-through guides from development to deployment
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Next.js - setup guide" icon="N" href="/guides/frameworks/nextjs">
|
||||
Learn how to setup Trigger.dev with Next.js, using either the pages or app router.
|
||||
</Card>
|
||||
|
||||
<Card
|
||||
title="Next.js - triggering tasks using webhooks"
|
||||
icon="N"
|
||||
href="/guides/frameworks/nextjs-webhooks"
|
||||
>
|
||||
Learn how to create a webhook handler for incoming webhooks in a Next.js app, and trigger a task from it.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### Task examples
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card
|
||||
title="Fal.ai with Realtime in Next.js"
|
||||
img="/images/fal-realtime-thumbnail.png"
|
||||
href="/guides/examples/fal-ai-realtime"
|
||||
>
|
||||
Generate an image from a prompt using Fal.ai and Trigger.dev Realtime.
|
||||
</Card>
|
||||
<Card
|
||||
title="Generate a cartoon using Fal.ai in Next.js"
|
||||
img="/images/fal-generate-cartoon-thumbnail.png"
|
||||
href="/guides/examples/fal-ai-image-to-cartoon"
|
||||
>
|
||||
Convert an image to a cartoon using Fal.ai.
|
||||
</Card>
|
||||
<Card
|
||||
title="Vercel sync environment variables"
|
||||
icon="code"
|
||||
href="/guides/examples/vercel-sync-env-vars"
|
||||
>
|
||||
Learn how to automatically sync environment variables from your Vercel projects to Trigger.dev.
|
||||
</Card>
|
||||
<Card title="Vercel AI SDK" icon="code" href="/guides/examples/vercel-ai-sdk">
|
||||
Learn how to use the Vercel AI SDK, which is a simple way to use AI models from different
|
||||
providers, including OpenAI, Anthropic, Amazon Bedrock, Groq, Perplexity etc.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
@@ -0,0 +1,3 @@
|
||||
<Warning>
|
||||
**WEB SCRAPING:** When web scraping, you MUST use a proxy to comply with our terms of service. Direct scraping of third-party websites without the site owner's permission using Trigger.dev Cloud is prohibited and will result in account suspension. See [this example](/guides/examples/puppeteer#scrape-content-from-a-web-page) which uses a proxy.
|
||||
</Warning>
|
||||
Reference in New Issue
Block a user