* Latest lockfile
* Updated Astro setup docs: env import
* Astro docs improvements
* Docs: improved the limitations
* Bumped package versions to 2.1.3
* Updated the Astro docs with SSR notes
* test/368/use vitest instead of jest (#470)
* chore: add vitest dependencies
* refactor: replace jest by vitest
* test: disable broken test
* Update pnpm-lock.yaml
* Update pnpm-lock.yaml
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* Created Temp for pull req, bugreport & feature req
* A few teaks to the templates
* Added instructions for how to do Changeset snapshots
* Redirect people to discord to ask a question
* Documentation Update: Added <github_username> instead of triggerdotdev to avoid confusion while cloning the repository (#477)
* add fastify package
* add fastify example
* update fastify docs
* add pnpm-lock
* update readme
* Added a link to the homepage from the side menu (#479)
* Added 2 new named icons
* New side menu link to the homepage
* Updated lock file
* Removed un-used import
* update client-adaptors for fastify
* Renamed the examples dir to references (true examples are in another repo and this was confusing)
* Add a references README
* Fixes broken pnpm lock file
* Improve the Astro manual setup guide
* Fixed cal.com link
* Upgrade to the latest remix (pre v2)
* React status hooks (#493)
* Added stripInternal to SDK tsconfig
* Statuses can now be set from a run, and are stored in the database
* Added the key to the returned status
* Made the test job have an extra step and only pass in some of the options
* client.getRunStatuses() and the corresponding endpoint
* client.getRun() now includes status info
* Fixed circular dependency schema
* Translate null to undefined
* Added the react package to the nextjs-reference tsconfig
* Removed unused OpenAI integration from nextjs-reference project
* New hooks for getting the statuses
* Disabled most of the nextjs-reference jobs
* Updated the hooks UI
* Updated the endpoints to deal with null statuses values
* The hook is working, with an example
* Changeset: “You can create statuses in your Jobs that can then be read using React hooks”
* Changeset config is back to the old changelog style
* WIP on new React hooks guide
* Guide docs for the new hooks
* Added the status hooks to the React hooks guide
* Removed the links to the status hooks reference for now
* Re-ordered the hooks
* Fix for an error in the docs
* Set a default of a blank array for the GetRunSchema
* Fixed dependency
* Revert "Upgrade to the latest remix (pre v2)"
This reverts commit 4edc7112ab.
* Update introduction.mdx (#498)
Changed https://github.com/triggerdotdev/examples/tree/main/resend (which was a 404) to https://github.com/triggerdotdev/examples/tree/main/resend-email-form
* Use the bell icon for the new status Tasks
* Going exponential with `Linear` (#478)
* Unleash GPT magic
* Clean up after GPT
* All the hooks
* Provisional integration catalog entry
* Sample webhook jobs
* Attachments with alpha warnings
* Remove some verbose logs
* Fix IP restrictions
* Remove tunnel
* Revert "Remove tunnel"
This reverts commit c5b69ce6524e3b40c26b66cdc56e087b8576b8c6.
* Resolve event name clashes
* Remove circular dependency
* Use correct payload uuid
* Schema fixes
* Fix webhook event name
* Start to Linearify catalog entry
* Remove todo
* More catalog updates
* Make OAuth work
* Rename webhook helper
* Schema juggling
* More discrimination
* Add Issue SLA event
* Simplify triggers
* Handle rate limits
* Fix Project schema
* Payload examples
* Improve event props
* Remove redundant source metadata
* One type to rule them all
* Recursive WithoutFunctions type
* Linear output serializer
* Some tasks
* Update catalog entry
* Dynamic usage sample
* Bump version
* Remove tunnel
* More tasks
* Add optional skipRetrying on runTask errors
* Fail fast on user errors
* Entity getter tasks
* Another couple of tasks
* Token to apiKey
* Sort tasks
* Add filtered issue SLA triggers
* Add docs
* Type fixes
* Job catalog examples
* Serialization helper docs
* Add changeset
* Refactor webhooks
* Enhance properties
* Pagination helper and docs
* Clean up imports
* Change misc catalog job
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* Use absolute image paths (#490)
* Update sendevent.mdx
* fix: Fail client-side on invalid Stripe event names (#492)
* Parse event names
* Add changeset
* feat: BYO Auth (#491)
* feat: BYO Auth
Define client-side auth resolvers to be able to supply custom authentication credentials for integrations before a run is performed
- Added new defineAuthResolver
- Update all integrations to support the new auth resolvers
- Strip internal symbols from .d.ts in integrations and trigger-sdk
- Added BYO Auth docs
- Update Dynamic Schedule to support associated account IDs
- Create external accounts just-in-time
- Added Account ID field to test job when there are external auth integrations
- Show Account ID on run dashboard
- Added new Run error state called “Unresolved auth”
* Added changeset
* Remove @internal from TriggerIntegration public methods
* Add void to the result union
* DynamicTriggers now work with the new BYO auth system, and added a bunch of docs and docs changes
* Add additional key material for registering dynamic trigger task
* Add new define* instance methods to the overview
* CLI now supports multiple frameworks (with tests) (#480)
* Early work defining CLI framework support
* WIP moving CLI init logic to the Framework class
* Installing files should now work for Nextjs
* Some fixes
* WIP creating unit tests for Next.js project detection
* Delete old jest config
* Latest lockfile
* Detect use of src directory test
* Tests for detection pages/app directory
* Correct detection of Next.js project
* Renamed test file
* Create install files from template files with replacements. With tests
* Added multiple uses of the same replacement
* Created a test for the install step (it fails right now with JS)
* Removed unused import
* Another test that should pass but currently fails…
* Path alias fixed and now has tests
* New pathAlias function used
* Nextjs page install tests
* Fixed app directory install (with tests)
* Removed e2e CLI test, switched to unit testing strategy instead
* Latest lockfile
* The install files are now actual files that are copied and transformed
* Got the template files working correctly after building
* Next steps are now framework specific
* createFileFromTemplate now works with a path again. Uses mock if specified.
* Renamed apiRoute.js to pagesApiRoute.js
* Simplified pages file generation
* Next.js app API route template
* Next.js App routing support, with common files logic shared
* Dev command now uses framework default values if they exist and aren’t overridden
* Unused import
* pathAlias now works for all frameworks
* Added a test to detect Next from the next.config.js
* WIP on Remix framework support
* Tests for Remix install
* Replaced references to Next.js
* Use a green ✔️ instead of ✅ in the CLI
* Support for multiple hostnames
* Tunneling can now use the hostname and port
* Work on multiple ports
* Improved the error messages. Added some extra pots to Next.js
* Update the Remix templates to have .server in the imports
* Remix updated to use server-runtime instead of node. Node v18+
* Frameworks can specify the watch paths and ignore paths
* Define the watch variables above, so we can easily log them for debugging
* Don’t wait for outdated package checking when running the dev command
* Improved the Remix manual setup guide
* Rewriting docs for quickstart
* Updated the Next.js quickstart
* Remix quick start
* Added a changeset
* Improved the Next.js manual setup
* Tweaked the Linear scopes
* Latest lockfile
* Fix for getPathAlias typecheck failure
* Linear getAll type error (weirdly not in VSCode…) and removed the pagination example that uses the SDK as won’t work with timeouts
* Add BYO auth for oauth options
* Add back in Job.toJSON to fix the testing package
* Removed dynamicTrigger @internal from toJSON
* The CLI now checks for a dev server API key in init and dev commands
* Remix onboarding now uses the CLI init command
* Decouple zod (#500)
Zod Schemas is no longer required for validating/inferring event triggers. We’ve taken inspiration from how domain-functions did it: https://github.com/seasonedcc/domain-functions/pull/114
* chore: Update version for release (#481)
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Latest lockfile
* feat: Basic usage dashboard to show run volume (#501)
* New usage dashboard with static data
* Implement org usage dash
* Grab chart data for the last 12 months
* If no org is found just return undefined so a 404 will be shown
* Remove mock data
* Fill in missing months with 0s
---------
Co-authored-by: James Ritchie <james@jamesritchie.co.uk>
* Fixed duplicate end month
* hotfix
* hotfix 2
* Astro CLI support (#506)
* Astro framework CLI support
* Changeset: Added Astro automatic installation
* Fixed the package name – was remix, now astro
* Fixed the export of the example
* Added IPv6 localhost to Astro hostnames
* Updated Astro onboarding to show the CLI init command, instead of manual instructions
* Astro quickstart
* Fix for type in Remix quickstart
* Next.js framework detection allows different config file extensions and “next” devDependency
* Made the dev command port more general so it works with various frameworks
* chore: Update version for release (#508)
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Fix for incorrectly named Next.js package in manual setup
* Latest lockfile
* Increased the intervalTrigger max from 1 day to 30 days
* Implement the task output redacting to prevent redacted values from showing in the logs
* Express frameworks docs + CLI (#512)
* Manual setup docs
* Added the onboarding
* The emails package now works with Node > 18
* Added CLi support for Express, including custom init command finished messages
* Need to actually log out the installation complete message…
* Fix for an old Remix reference
* Renamed the page export
* Use resolvedOptions.triggerUrl
* Typo in manual instructions
* chore: Update version for release (#513)
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Latest lockfile
* Add the STAGING environment by default
* Fixed sparodically failed run creations
- Use a better way of getting the latest job run number to increment
- Make the CreateRunService transaction more reliable
- Invoke dispatchers in parallel
- No longer swallow prisma errors in $transaction
* Swapped out the Homepage link in the side menu for a link to the Changelog
* Youtube embedded video fits its aspect ratio instead of going full width
* Improved CLI init Next.js middleware detection
* CLI init: adds public key as “TRIGGER_PUBLIC_API_KEY” except for Next which overrides this
* Updated the docs for the React hooks
* chore: Update version for release (#521)
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Display framework logos on the onboarding setup pages (#519)
* autofocus the search field on the Job page
* Add some documentation around canceling scheduled events
* Updated outdated lockfile
* Updated docs README.md
* Improves the performance of run resuming (#522)
* Improves the perform of run resuming
When runs resume, we try and make sure that tasks that have already been completed are cached and reused. Worst case scenario the client needs to hit the API server once for a non-cached task that is indeed completed on the server, but this can get pretty expensive when there are a larger number of tasks.
This commit does 2 different things to help:
- noop tasks are no longer “cached” using the cachedTasks strategy, instead their idempotency keys are shoved into a bloom filter and the client tests for their inclusion in the bloom filter before running them (since they don’t have any concept of output, this works)
- Additional cached tasks are lazy loaded when a task is run. This allows us to progressively fetch additional tasks to be cached on the client, which will cut down on cache misses by a decent amount
* Create warm-carrots-float.md
* Make io.yield backwards compat with older platform versions
* Better support old clients connecting to server versions that support lazy loading cached tasks
* Fixed type errors when settings headers with unknown value
* Better yield not support error message
* Rename _version to _serverVersion to be more clear
* Add typed filters to `Linear` getAll helper (#517)
* Fix getAll params type
* Changeset
* Search param types
* Update changeset
* `Replicate` integration and remote callbacks (#507)
* Support tasks with remote callbacks
* Add common integration tsconfig
* Add Replicate integration
* Basic job catalog example
* Integration catalog entry
* Check for callbackUrl during executeTask
* Fix getAll
* Improve JSDoc
* Bump version
* Remove named queue
* Simplify runTask types
* Trust the types
* Fail tasks on timeout
* Callback timeout as param
* Mess with types
* performRunExecutionV1
* Update runTask docs
* Shorten callback task methods
* Fix run method return type
* Image processing jobs
* Replicate docs
* Text output example
* Changeset
* Version bump
* Roll back ugly types
* Remove missing types
* Quicker return when waiting on remote callback
* Remote callback example
* Bump version
* Remove schema parsing
* Only schedule positive callback timeout
* Decrease callback secret length
* Explicit default timeouts
* Import deployments tasks
* JSDoc
* Deployments docs
* Fix runTask examples, mention wrappers
---------
Co-authored-by: Eric Allam <eric@trigger.dev>
* Update pnpm lock file
* Allow blank issues
* chore: Update version for release (#538)
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Fix pnpm lock file
* feat: New Test page (#558)
* Improvements to the shortcut keys
* Updated code mirror theme to the new dark mode style
* Removed the old test page help panel copy
* WIP new structure for the test page
* Added some of the side panel options for examples and account ID
* Conditionally hide the side panel components if they’re blank
* Example with selected state working
* Allow selecting the example again to overwrite any edits
* Previous run payloads working
* Select a recent payload if there’s no example
* Created Icon and DetailCell components
* The integrations now use the DetailCell
* Use DetailCell on the integrations page
* Added support for description to DetailCell. With proper variants now
* DateTimeAccurate and formatDateTimeAccurate weren’t displaying correctly.
fractionalSecondDigits isn’t in the types, but is supported for 92.5% of users
* DetailCell now allows label and description to be React components
* Using the DetailCell on the Test page
* Styled the CodeMirror scrollbars to match elsewhere
* Adding copy and clear to the JSONEditor, not working properly yet though
* Removed the copy/clear buttons from the Test route
* Delete the light color theme
* The editor now supports copying/clearing etc
* Made it clear when text is copied
* Changed the learn link to a tertiary button
* Fixed CMD shortcut keys
* Run test button now works with ⌘ Enter
* CodeMirror now allows ⌘Enter to escape the field
* Added JSON linter to the test editor
* Fix for buttons not being aligned correctly
* Copy/clear buttons now aligned
* Made the integration DetailCell text smaller
* The test recent payloads now have colored text to help identify the status
* DetailCell descriptions are dimmer
* Added link to docs for BYOA
* Fix for buttons going full width when they shouldn’t
---------
Co-authored-by: James Ritchie <james@jamesritchie.co.uk>
* chore: update doc title for groups (#539)
* chore: update doc title for groups
* update docs for sdk and integrations
* Add instructions for triggering job runs to the job catalog readme
* Updated the Test docs
* Removed a console.log when a user’s file is changed that CLI dev is listening for
* feat: allow cancelling jobs from trigger-client sdk (#562)
* feat: allow cancelling jobs from trigger-client sdk
* use presenter instead of service for non-mutating logic
* chore: upgrade zod to 3.22.3 (#570)
* chore: upgrade zod to 3.22.3
* add changeset
* Stringify event payload and context before serialization
This fixes an issue where an event payload was being serialized through remix-typedjson and was causing issues with incorrect meta keys and so deserialization was failing. See https://github.com/kiliman/remix-typedjson/pull/33 for more
* Need to properly format the payload JSON
* NestJS framework suport (from @H4ad) (#574)
* feat: added nestjs package adapter
* Latest lockfile
* Updated Astro setup docs: env import
* Astro docs improvements
* Docs: improved the limitations
* Bumped package versions to 2.1.3
* Updated the Astro docs with SSR notes
* test/368/use vitest instead of jest (#470)
* chore: add vitest dependencies
* refactor: replace jest by vitest
* test: disable broken test
* Update pnpm-lock.yaml
* Update pnpm-lock.yaml
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* Created Temp for pull req, bugreport & feature req
* A few teaks to the templates
* Added instructions for how to do Changeset snapshots
* Redirect people to discord to ask a question
* Documentation Update: Added <github_username> instead of triggerdotdev to avoid confusion while cloning the repository (#477)
* Added a link to the homepage from the side menu (#479)
* Added 2 new named icons
* New side menu link to the homepage
* Updated lock file
* Removed un-used import
* Renamed the examples dir to references (true examples are in another repo and this was confusing)
* Add a references README
* Fixes broken pnpm lock file
* Improve the Astro manual setup guide
* Fixed cal.com link
* Upgrade to the latest remix (pre v2)
* React status hooks (#493)
* Added stripInternal to SDK tsconfig
* Statuses can now be set from a run, and are stored in the database
* Added the key to the returned status
* Made the test job have an extra step and only pass in some of the options
* client.getRunStatuses() and the corresponding endpoint
* client.getRun() now includes status info
* Fixed circular dependency schema
* Translate null to undefined
* Added the react package to the nextjs-reference tsconfig
* Removed unused OpenAI integration from nextjs-reference project
* New hooks for getting the statuses
* Disabled most of the nextjs-reference jobs
* Updated the hooks UI
* Updated the endpoints to deal with null statuses values
* The hook is working, with an example
* Changeset: “You can create statuses in your Jobs that can then be read using React hooks”
* Changeset config is back to the old changelog style
* WIP on new React hooks guide
* Guide docs for the new hooks
* Added the status hooks to the React hooks guide
* Removed the links to the status hooks reference for now
* Re-ordered the hooks
* Fix for an error in the docs
* Set a default of a blank array for the GetRunSchema
* Fixed dependency
* Revert "Upgrade to the latest remix (pre v2)"
This reverts commit 4edc7112ab.
* Update introduction.mdx (#498)
Changed https://github.com/triggerdotdev/examples/tree/main/resend (which was a 404) to https://github.com/triggerdotdev/examples/tree/main/resend-email-form
* Use the bell icon for the new status Tasks
* Going exponential with `Linear` (#478)
* Unleash GPT magic
* Clean up after GPT
* All the hooks
* Provisional integration catalog entry
* Sample webhook jobs
* Attachments with alpha warnings
* Remove some verbose logs
* Fix IP restrictions
* Remove tunnel
* Revert "Remove tunnel"
This reverts commit c5b69ce6524e3b40c26b66cdc56e087b8576b8c6.
* Resolve event name clashes
* Remove circular dependency
* Use correct payload uuid
* Schema fixes
* Fix webhook event name
* Start to Linearify catalog entry
* Remove todo
* More catalog updates
* Make OAuth work
* Rename webhook helper
* Schema juggling
* More discrimination
* Add Issue SLA event
* Simplify triggers
* Handle rate limits
* Fix Project schema
* Payload examples
* Improve event props
* Remove redundant source metadata
* One type to rule them all
* Recursive WithoutFunctions type
* Linear output serializer
* Some tasks
* Update catalog entry
* Dynamic usage sample
* Bump version
* Remove tunnel
* More tasks
* Add optional skipRetrying on runTask errors
* Fail fast on user errors
* Entity getter tasks
* Another couple of tasks
* Token to apiKey
* Sort tasks
* Add filtered issue SLA triggers
* Add docs
* Type fixes
* Job catalog examples
* Serialization helper docs
* Add changeset
* Refactor webhooks
* Enhance properties
* Pagination helper and docs
* Clean up imports
* Change misc catalog job
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* Use absolute image paths (#490)
* Update sendevent.mdx
* fix: Fail client-side on invalid Stripe event names (#492)
* Parse event names
* Add changeset
* feat: BYO Auth (#491)
* feat: BYO Auth
Define client-side auth resolvers to be able to supply custom authentication credentials for integrations before a run is performed
- Added new defineAuthResolver
- Update all integrations to support the new auth resolvers
- Strip internal symbols from .d.ts in integrations and trigger-sdk
- Added BYO Auth docs
- Update Dynamic Schedule to support associated account IDs
- Create external accounts just-in-time
- Added Account ID field to test job when there are external auth integrations
- Show Account ID on run dashboard
- Added new Run error state called “Unresolved auth”
* Added changeset
* Remove @internal from TriggerIntegration public methods
* Add void to the result union
* DynamicTriggers now work with the new BYO auth system, and added a bunch of docs and docs changes
* Add additional key material for registering dynamic trigger task
* Add new define* instance methods to the overview
* CLI now supports multiple frameworks (with tests) (#480)
* Early work defining CLI framework support
* WIP moving CLI init logic to the Framework class
* Installing files should now work for Nextjs
* Some fixes
* WIP creating unit tests for Next.js project detection
* Delete old jest config
* Latest lockfile
* Detect use of src directory test
* Tests for detection pages/app directory
* Correct detection of Next.js project
* Renamed test file
* Create install files from template files with replacements. With tests
* Added multiple uses of the same replacement
* Created a test for the install step (it fails right now with JS)
* Removed unused import
* Another test that should pass but currently fails…
* Path alias fixed and now has tests
* New pathAlias function used
* Nextjs page install tests
* Fixed app directory install (with tests)
* Removed e2e CLI test, switched to unit testing strategy instead
* Latest lockfile
* The install files are now actual files that are copied and transformed
* Got the template files working correctly after building
* Next steps are now framework specific
* createFileFromTemplate now works with a path again. Uses mock if specified.
* Renamed apiRoute.js to pagesApiRoute.js
* Simplified pages file generation
* Next.js app API route template
* Next.js App routing support, with common files logic shared
* Dev command now uses framework default values if they exist and aren’t overridden
* Unused import
* pathAlias now works for all frameworks
* Added a test to detect Next from the next.config.js
* WIP on Remix framework support
* Tests for Remix install
* Replaced references to Next.js
* Use a green ✔️ instead of ✅ in the CLI
* Support for multiple hostnames
* Tunneling can now use the hostname and port
* Work on multiple ports
* Improved the error messages. Added some extra pots to Next.js
* Update the Remix templates to have .server in the imports
* Remix updated to use server-runtime instead of node. Node v18+
* Frameworks can specify the watch paths and ignore paths
* Define the watch variables above, so we can easily log them for debugging
* Don’t wait for outdated package checking when running the dev command
* Improved the Remix manual setup guide
* Rewriting docs for quickstart
* Updated the Next.js quickstart
* Remix quick start
* Added a changeset
* Improved the Next.js manual setup
* Tweaked the Linear scopes
* Latest lockfile
* Fix for getPathAlias typecheck failure
* Linear getAll type error (weirdly not in VSCode…) and removed the pagination example that uses the SDK as won’t work with timeouts
* Add BYO auth for oauth options
* Add back in Job.toJSON to fix the testing package
* Removed dynamicTrigger @internal from toJSON
* The CLI now checks for a dev server API key in init and dev commands
* Remix onboarding now uses the CLI init command
* Decouple zod (#500)
Zod Schemas is no longer required for validating/inferring event triggers. We’ve taken inspiration from how domain-functions did it: https://github.com/seasonedcc/domain-functions/pull/114
* chore: Update version for release (#481)
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Latest lockfile
* feat: Basic usage dashboard to show run volume (#501)
* New usage dashboard with static data
* Implement org usage dash
* Grab chart data for the last 12 months
* If no org is found just return undefined so a 404 will be shown
* Remove mock data
* Fill in missing months with 0s
---------
Co-authored-by: James Ritchie <james@jamesritchie.co.uk>
* Fixed duplicate end month
* hotfix
* hotfix 2
* Astro CLI support (#506)
* Astro framework CLI support
* Changeset: Added Astro automatic installation
* Fixed the package name – was remix, now astro
* Fixed the export of the example
* Added IPv6 localhost to Astro hostnames
* Updated Astro onboarding to show the CLI init command, instead of manual instructions
* Astro quickstart
* Fix for type in Remix quickstart
* Next.js framework detection allows different config file extensions and “next” devDependency
* Made the dev command port more general so it works with various frameworks
* chore: Update version for release (#508)
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Fix for incorrectly named Next.js package in manual setup
* Latest lockfile
* Increased the intervalTrigger max from 1 day to 30 days
* Implement the task output redacting to prevent redacted values from showing in the logs
* Express frameworks docs + CLI (#512)
* Manual setup docs
* Added the onboarding
* The emails package now works with Node > 18
* Added CLi support for Express, including custom init command finished messages
* Need to actually log out the installation complete message…
* Fix for an old Remix reference
* Renamed the page export
* Use resolvedOptions.triggerUrl
* Typo in manual instructions
* chore: Update version for release (#513)
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Latest lockfile
* Add the STAGING environment by default
* Fixed sparodically failed run creations
- Use a better way of getting the latest job run number to increment
- Make the CreateRunService transaction more reliable
- Invoke dispatchers in parallel
- No longer swallow prisma errors in $transaction
* Swapped out the Homepage link in the side menu for a link to the Changelog
* Youtube embedded video fits its aspect ratio instead of going full width
* Improved CLI init Next.js middleware detection
* CLI init: adds public key as “TRIGGER_PUBLIC_API_KEY” except for Next which overrides this
* Updated the docs for the React hooks
* chore: Update version for release (#521)
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Display framework logos on the onboarding setup pages (#519)
* autofocus the search field on the Job page
* Add some documentation around canceling scheduled events
* Updated outdated lockfile
* Updated docs README.md
* Improves the performance of run resuming (#522)
* Improves the perform of run resuming
When runs resume, we try and make sure that tasks that have already been completed are cached and reused. Worst case scenario the client needs to hit the API server once for a non-cached task that is indeed completed on the server, but this can get pretty expensive when there are a larger number of tasks.
This commit does 2 different things to help:
- noop tasks are no longer “cached” using the cachedTasks strategy, instead their idempotency keys are shoved into a bloom filter and the client tests for their inclusion in the bloom filter before running them (since they don’t have any concept of output, this works)
- Additional cached tasks are lazy loaded when a task is run. This allows us to progressively fetch additional tasks to be cached on the client, which will cut down on cache misses by a decent amount
* Create warm-carrots-float.md
* Make io.yield backwards compat with older platform versions
* Better support old clients connecting to server versions that support lazy loading cached tasks
* Fixed type errors when settings headers with unknown value
* Better yield not support error message
* Rename _version to _serverVersion to be more clear
* Add typed filters to `Linear` getAll helper (#517)
* Fix getAll params type
* Changeset
* Search param types
* Update changeset
* `Replicate` integration and remote callbacks (#507)
* Support tasks with remote callbacks
* Add common integration tsconfig
* Add Replicate integration
* Basic job catalog example
* Integration catalog entry
* Check for callbackUrl during executeTask
* Fix getAll
* Improve JSDoc
* Bump version
* Remove named queue
* Simplify runTask types
* Trust the types
* Fail tasks on timeout
* Callback timeout as param
* Mess with types
* performRunExecutionV1
* Update runTask docs
* Shorten callback task methods
* Fix run method return type
* Image processing jobs
* Replicate docs
* Text output example
* Changeset
* Version bump
* Roll back ugly types
* Remove missing types
* Quicker return when waiting on remote callback
* Remote callback example
* Bump version
* Remove schema parsing
* Only schedule positive callback timeout
* Decrease callback secret length
* Explicit default timeouts
* Import deployments tasks
* JSDoc
* Deployments docs
* Fix runTask examples, mention wrappers
---------
Co-authored-by: Eric Allam <eric@trigger.dev>
* Update pnpm lock file
* Allow blank issues
* chore: Update version for release (#538)
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Fix pnpm lock file
* feat: New Test page (#558)
* Improvements to the shortcut keys
* Updated code mirror theme to the new dark mode style
* Removed the old test page help panel copy
* WIP new structure for the test page
* Added some of the side panel options for examples and account ID
* Conditionally hide the side panel components if they’re blank
* Example with selected state working
* Allow selecting the example again to overwrite any edits
* Previous run payloads working
* Select a recent payload if there’s no example
* Created Icon and DetailCell components
* The integrations now use the DetailCell
* Use DetailCell on the integrations page
* Added support for description to DetailCell. With proper variants now
* DateTimeAccurate and formatDateTimeAccurate weren’t displaying correctly.
fractionalSecondDigits isn’t in the types, but is supported for 92.5% of users
* DetailCell now allows label and description to be React components
* Using the DetailCell on the Test page
* Styled the CodeMirror scrollbars to match elsewhere
* Adding copy and clear to the JSONEditor, not working properly yet though
* Removed the copy/clear buttons from the Test route
* Delete the light color theme
* The editor now supports copying/clearing etc
* Made it clear when text is copied
* Changed the learn link to a tertiary button
* Fixed CMD shortcut keys
* Run test button now works with ⌘ Enter
* CodeMirror now allows ⌘Enter to escape the field
* Added JSON linter to the test editor
* Fix for buttons not being aligned correctly
* Copy/clear buttons now aligned
* Made the integration DetailCell text smaller
* The test recent payloads now have colored text to help identify the status
* DetailCell descriptions are dimmer
* Added link to docs for BYOA
* Fix for buttons going full width when they shouldn’t
---------
Co-authored-by: James Ritchie <james@jamesritchie.co.uk>
* chore: update doc title for groups (#539)
* chore: update doc title for groups
* update docs for sdk and integrations
* Add instructions for triggering job runs to the job catalog readme
* Updated the Test docs
* Removed a console.log when a user’s file is changed that CLI dev is listening for
* feat: allow cancelling jobs from trigger-client sdk (#562)
* feat: allow cancelling jobs from trigger-client sdk
* use presenter instead of service for non-mutating logic
* chore: upgrade zod to 3.22.3 (#570)
* chore: upgrade zod to 3.22.3
* add changeset
* Created a changeset with the correct starting package version
* Added headers to NestJS response
* Added some types to the NestJS project
* Added fastify types
* Removed log from CodeMirror
* Added InstallPackages component
* Improved the NestJS onboarding instructions
* Updated the onboarding instructions
* Made all the quickstart framework cards snippets, so the page isn’t a nightmare to edit
* NestJS docs updates
* Added dotenv to the earlier code sample
* Latest lockfile
* Moved the nestjs-example to the reference folder
---------
Co-authored-by: Vinícius Lourenço <contact@viniciusl.com.br>
Co-authored-by: Wesley <100464352+ologbonowiwi@users.noreply.github.com>
Co-authored-by: Vishesh Rawal <92795514+visheshrwl@users.noreply.github.com>
Co-authored-by: Eric Allam <eallam@icloud.com>
Co-authored-by: Aniket Bindhani <aniketbindhani44@gmail.com>
Co-authored-by: James Ritchie <james@trigger.dev>
Co-authored-by: D-K-P <dkp.github@pm.me>
Co-authored-by: Gregory <93215236+gjohnsx@users.noreply.github.com>
Co-authored-by: nicktrn <55853254+nicktrn@users.noreply.github.com>
Co-authored-by: Eric Allam <eric@trigger.dev>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: James Ritchie <james@jamesritchie.co.uk>
Co-authored-by: Hemachandar <132386067+hmacr@users.noreply.github.com>
* chore: Update version for release (#571)
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Latest lockfile
* Removed NestJS example project tests
* Removed testing dependencies from nestjs example
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
Co-authored-by: Wesley <100464352+ologbonowiwi@users.noreply.github.com>
Co-authored-by: Vishesh Rawal <92795514+visheshrwl@users.noreply.github.com>
Co-authored-by: Eric Allam <eallam@icloud.com>
Co-authored-by: Aniket Bindhani <aniketbindhani44@gmail.com>
Co-authored-by: James Ritchie <james@trigger.dev>
Co-authored-by: D-K-P <dkp.github@pm.me>
Co-authored-by: Gregory <93215236+gjohnsx@users.noreply.github.com>
Co-authored-by: nicktrn <55853254+nicktrn@users.noreply.github.com>
Co-authored-by: Eric Allam <eric@trigger.dev>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: James Ritchie <james@jamesritchie.co.uk>
Co-authored-by: Hemachandar <132386067+hmacr@users.noreply.github.com>
Co-authored-by: Vinícius Lourenço <contact@viniciusl.com.br>
* updated the @trigger.dev/astro package to support typescript
* set up a example astro project
* docs: manual setup of Trigger.dev in an Astro project
* doc: updated the manual setup docs for astro
* updated the webapp onboarding for astro
* cleaned up the example astro project
* removed next from dependency 😅
* updated the readme
* moved trigger.ts file and job folder to src directory
* created a .env.example file
* updated tsconfig
* updated to use aliases
* updated package.json
* updated the astro onboarding page
* updated the manual installation guide for astro
* updated to use alias
* added astro as a dev dependency
* Remove extra comma I left in
* Changed Object.create() to a Record, so we have some type safety
* Added the localhost URL to the API in the Astro example
* Added the TRIGGER_API_URL to the trigger client in the example
* Added the CLI dev dependency to the Astro example
* Update the running instructions to be closer to Remix's
* Create friendly-carpets-collect.md
* Fix bad package name for Astro
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* fix: Added retry config and showed error from subtask in web
* Still fallback to "Task errored" if there's no output
* Create rude-carrots-enjoy.md
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* init remix project
* feat: implemented the remix adapter package
* updated the remix package to return the action variable
* added an example job to the example remix project
* fix: Ensure Side Effects Execution in Remix API Routes
* updated the readme in @trigger.dev/remix package
* doc: added the manual setup guide for remix
* updated the webapp onboarding for remix
* updated the manual setup guide
* added a license to the @trigger.dev/remix package
* added a wait function to the example job
* added a link to the remix webapp onboarding
* Updated the onboarding page
For now, we'll only support existing projects. The button that links to the manual installation was just a blank rectangle – added some text to it.
* Added the Server API key to the instructions
* Remix manual docs
Made some things a bit clearer
- file paths
- exporting the job rather than using a function wrapper
- how to run the app and CLI dev command
* Export the job
* Update api.trigger.ts
* Added tsconfig.json paths
* Remove next dependency
* Package set to 2.1.0 and set dependencies
Shouldn't rely on a specific version in main dependencies. In this case we can just have devDependency for @remix/node
* Changeset
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* feat: add proxy support for node-fetch
This process is expected to allow the CLI and SDK to work in environments where proxy is enabled.
* Revert "feat: add proxy support for node-fetch"
This reverts commit c850030b5927c562921409fc5b798af353a7ac6b.
* feat: add proxy support for node-fetch (CLI only)
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* feat: add testing package
* feat: add unit testing example
* Delete examples/unit-testing/dummy-integration/tasks.ts
* Delete examples/unit-testing/dummy-integration/types.ts
* Update DummyIntegration to new format
* Update testing package to new integration format
* Update readme to new task spy format
* Create rotten-meals-cough.md
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* Removed next references in the ReadMe
* FAQ improvements to update Next.js references
* Added a new Frameworks page with logos to link to the quick start guides
* Renamed the mdx file so the link works
* Added basic platform guides
* Introduction doesn’t reference next.js only
* Added a note about serverless and restructured the side menu
* Added more frameworks pages to the manual install section
* Fixed SVG error
* Coming soon guides now using snippets so they can be in 2 places while we work on them
* Removed redirects
* Added a new named icon
* increased fireworks particle count slightly
* Creating a route for the onboarding and link to access it anytime from the side menu
* Moved the onboarding into new components
* Updated the routes for the onboarding page
* Onboarding is now Setup and the frameworks overview page now links to different framework page in the onboarding side nav
* URLs and pages renamed to ‘setup’
* URLs and pages renamed to ‘setup’
* Fixed some old named component imports
* WIP on a new less hacked-in background image
* Added svg logos for all the frameworks
* New paths for the new framework pages
* Side menu collapses once you selected a framework
* Temporary Nuxt page
* New routes for the new frameworks
* New ‘framework coming soon’ component - now used in the coming soon framework pages
* Moved/removed files
* Moved all svg framework logos into a new folder and file
* balanced the logo sizes
* Framework coming soon pages take a name and url
* New express svg logo
* New component for a Framework item in the grid
* Added information and design for the coming soon frameworks
* Change the grid to 1 row if jobs === 0
* Updated the framework coming soon snippet and added it to the relevant pages
* Express now 2nd in all lists
* Added link to long running server support discussion
* New logo to include next.js + supabase quick start
* roadmap now links to homepage with page anchor to roadmap section
* changelog now links to Github releases page
* Removed reference to Next.js
* Docs pages with coming soon info all share the same framework snippets
* Fixed issue of missing props
* Moved the fireworks effect into a separate file to make it easier for adding more framework onboarding pages
* Info callouts have a more muted style
* Added a callout to the top of the next onboarding to reference Serverless-only support
* Moved the callout explaining scheduled triggers not working in dev to the bottom of the test panel
This is to resolve eric’s UX ticket: https://github.com/triggerdotdev/trigger.dev/issues/416
* Added groundwork for Nest.js framework
* Using framer motion for the menu transition instead of css - now has a slight spring and is snappier
* redirect the manual setup page to the new nextjs setup page
* Fixed broken docs link
* Added a readme.md to next.js package
* Capital I for integration
* Renamed component: NextDevCommand to RunDevCommand
* Made required props non-optional
* CLI now points at manual install guides if no Next project detected
* Explicitly made supported default to false (it was working but a bit hard to read)
* Added links to all github issues for the frameworks coming soon component
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* Added ‘our progress’ table to the readme
* Added link to the connect discussion to the progress table
* Removed link from "Polling Triggers"
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* fix: use NODE_ENV when starting from docker image
When starting from `pnpm run start`, NODE_ENV is fixed to production, causing problems like #186.
So, I added `start_docker`, a process dedicated to docker, and started from it.
The process is exactly the same as `start` except that NODE_ENV is not overwritten.
* fix: align execution name with others
* Change: command name to match review
* CLI create-integration command now accepts an Open AI api key
* Create integration docs separated into multiple pages
* Initial Airtable integration commit, with OpenAI generated code
* OAuth page coming soon
* Export DisplayProperty from the SDK
* TSConfig made to match GitHub’s with paths
* getRecords
* Removed duplicate Stripe job from the catalog
* Renamed Airtable apiKey option to token
* First Airtable job
* Export Collaborator and Attachment field types
* A typesafe example that uses runTask
* WIP on new integration tasks… not working yet
* Attempt with class
* Revert "Attempt with class"
This reverts commit 93a48330019f754c3216c5b49964fa4b0218bd3f.
* WIP changing how tasks work
* Mock of async local storage
* Moved client creation from constructor
* New approach with a clone method on TriggerIntegration
* Added runTask to Airtable which is used by integration tasks
* Added the Airtable icon and connection when using runTask
* base().table() is working
* runTask options moved to the 3rd param, made optional with optional name
* Added some generic arguments
* Added generic type to table
* Removed old comment
* We don’t need to repeat the icon
* getRecords and getRecord now returning the right data and types
* Creating records
* Update records
* Delete records
* The internal properties of integrations are now hidden by the TypeScript types
* Sprinkled a Prettify in there
* Improved the types
* Added Airtable to the integration catalog
* Early work on Airtable webhook registration
* More progress with webhooks
* connectionKey needs to be cloned for webhooks to work
* connectionKey needs to be cloned for webhooks to work
* It was unclear that the ActivateSourceService was using a graphileJob id
* ActivateSourceService optionally takes a jobId, if missing it generate a unique id
* When retrying trigger registration, don’t pass an id so it is generated
* Removed Airtable webhooks tasks from the job-catalog example
* Added TriggerSourceOption, removed TriggerSourceEvent
* WIP with new ExternalSource options
* ExternalSourceTrigger setup
* DynamicTrigger changed to options, will need some more work
* filter gets options passed to it
* SourceMetadata v2 renamed to SourceMetadataV2, kept original
* Started versioning the backend
* Moved param order on io.getEvent and io.cancelEvent
* The runTask stuff that allows unknown to work is back
* Indexing for v1 and v2, with version on “activateSource” schema
* Added todos, to deal with Airtable SDK calls inside the webhook handler
* “deliverHttpSourceRequest” queueName changed to the source id so they process in order
* ActivateSource changes to deal with old and new data formats
* Update existing TriggerSources to v2
* Fix for dynamic.ts typescript errors, need to revisit this later
* UpdateSourceService v1 and v2, with new v2 API endpoint
* Removed unused imports
* More progress on v1 and v2
* Airtable webhooks are now triggering a job
* Moved webhooks to a new file
* You can do API calls in the webhook handler now, Airtable webhook data is being processed
* Airtable events coming through
* Defined the Airtable table payload type
* TriggerSource metadata is being stored and used
* Removed some logs
* Added filtering and don’t allow any webhooks that use automated sources
* Resend switched to new integration
* Moved Resend test jobs to the catalog, and tested it worked
* WIP on Slack, there are compile errors
* Created a generic type that strips out indexes
* Slack updated to use new integration
* SendGrid migrated over
* Integration runTask is now allowing regular types
* Changed io.runTask types so it only allows Json-able types
* OpenAI models tasks working
* Added Airtable changes to runTask
* Removed the index signature crap from the Slack integration
* Don’t need to cast the callback result
* Updated Resend
* Re-ordered runTask params
* WIP on openai
* onAccountUpdated is Connect only
* Removed RunTaskResult
* Handle Resend errors, the official SDK doesn’t expose them properly at the moment
* Removed OmitIndexSignature
* OpenAI converted to new integration, with backwards compatible functions
* Put the openai catalog back to what it was originally
* Export a standard retry with backoff, to be used
* Use the standard exponential backoff in the integrations
* Retry options moved earlier so they can be overriden by a task
* GitHub tasks migrated
* Added sources, fixed one bundling issue
* Added GitHub jobs to catalog
* Remove duplicate options
* Deduplicate events
* Removed duplicate Job
* Switched Plain over
* Set the Plain icon
* Converted Stripe over
* Supabase adapted
* Typeform working
* Added dynamic-schedule to catalog
* Added background-fetch job catalog
* Created dynamic-triggers catalog file
* Fixed old general file with runTask param order
* Dynamic triggers working
* SendGrid updated to use the same tsconfig as other integrations
* Removed Airtable webhook, until we have batch support
* Added OAuth airtable auth example
* Created beta changeset tag
* Beta changesets for most packages
---------
Co-authored-by: Eric Allam <eallam@icloud.com>
This commit fixes various issues with run executions, including a pretty gnarly memory bloat issue when resuming a run that had a decent number of completed tasks (e.g. anything over a few). Other issues fixed:
- Run executions no longer are bound to a queue, which will allow more parallel runs in a single job (instead of 1).
- Serverless function timeouts (504) errors are now handled better, and no longer are retried using the graphile worker failure/retry mechanism (causing massive delays).
- Fixed the job_key design of the performRunExecutionV2 task, which will ensure resumed runs are executed
- Added a mechanism to measure the amount of execution time a given run has accrued, and added a maximum execution duration on the org to be able to limit total execution time for a single run
Performance degradation came from the syntax highlighting of large code blocks and from doing that on the server and the client, so fixed this in a couple of ways:
1. Stream the task details data using defer and Suspense/Await
2. Skipped syntax highlighting code blocks with more than 1k lines
* #344 Upgrading the openai package to v4
* Create neat-roses-wait.md
* Fixed a couple of issues with the openai v4 upgrade
* Added fine tuning job tasks
* Don’t show the Ready To Run Job prompt if you have an Integration that needs attention
* Don’t highlight the row red or green
* Improvements to the contrast of the app sections and dividers
* Removed the Jobs page title as it’s duped info
* using the new border variable
* Sticky last table cell
* Improved the sticky last table cell
* Make any last cell in a table sticky by adding isSticky to it
* Added a dropdown menu to the menu table cell
* table rows can be marked as disabled by adding disabled
* Using the jobTestPath function for the test path
* tidy up imports
* Removed un-used props
* Removed the green badge variant
* Added a new status badge to the Runs table
* Clicking the gradient clicks the row
* Delete Job triggers a modal popup
* Added a large danger button type
* Added some modal styling and started adding data
* Added more styling and data to the delete job modal
* A table can now be given a full width prop
* Large danger button added to Storybook
* Danger button disabled state looks disabled now
* New active badge component to display in the table and logic for showing the env data
* Style updates to the dialog component
* active and job status badges can now have a small size
* Added a new named icon
* The Job page shows the Job status in the PageInfoRow
* Small badge style update
* Runs table has a sticky right cell
* Created a JobStatusTable component
* Added some placeholder help panel content for disabling a Job
* WIP creating a Settings page
* Added a delete button that triggers the delete modal – just need data hooking up
* Implemented deleting jobs from the dashboard
---------
Co-authored-by: Eric Allam <eallam@icloud.com>
* feat: introduce support for native astro integration package
Signed-off-by: Liran Tal <liran.tal@gmail.com>
* fix: update license copyright to match other packages from trigger
Signed-off-by: Liran Tal <liran.tal@gmail.com>
* fix: doc update to refer to the official astro package from trigger
Signed-off-by: Liran Tal <liran.tal@gmail.com>
* fix: repo URLs update accordingly to official repo
Signed-off-by: Liran Tal <liran.tal@gmail.com>
* fix: remove myself as author of the package to not confuse people
Signed-off-by: Liran Tal <liran.tal@gmail.com>
* Remove package-lock because this is now in the pnpm monorepo
---------
Signed-off-by: Liran Tal <liran.tal@gmail.com>
Co-authored-by: Eric Allam <eallam@icloud.com>
* feat: add hostname option to the dev command
- This commit adds a `hostname` option to the cli `dev` command, to allow the cli to point to nextjs applications running on different hostnames other than `localhost`. Example: the nextjs app was started using a --hostname 0.0.0.0 option to be able to be visible from inside docker containers. So adding --hostname 0.0.0.0 to `trigger-cli dev` would make it work.
* docs: add dev cli command hostname option documentation
* feat: add hostname option to the dev command
- This commit adds a `hostname` option to the cli `dev` command, to allow the cli to point to nextjs applications running on different hostnames other than `localhost`. Example: the nextjs app was started using a --hostname 0.0.0.0 option to be able to be visible from inside docker containers. So adding --hostname 0.0.0.0 to `trigger-cli dev` would make it work.
* docs: add dev cli command hostname option documentation
* Update hip-coins-reply.md
---------
Co-authored-by: Eric Allam <eallam@icloud.com>
* WIP job run performance improvements
- Added a `perf` tool to better measure job run performance under heavy load
- Removed `runFinished` job (not really needed)
- startQueuedRuns now uses a jobKey with replace
- Fixed an issue with ZodWorker when using jobKey
* Publish improvement docker images
* fixed the improvement docker publishing
* Downgrade back to prisma 4.16.0 because 5.1.x broke docker builds
* Changes to how queued runs work
- Split the worker into two different workers, one dedicated to performRunExecution
- Schedule performRunExecution in a single place, with a queue and using a round robin manually controlled concurrency
- Remove startQueuedRuns
- All runs are queued before they are started
- Setting the worker maxPoolSize to the same as the worker concurrency
- Starting to be able to split the docker image
* Remove queue name from startRun graphile job
* Make the prisma connection pool stuff configurable through env vars
* Hardcode (for now) the max concurrent runs limit
* Rewrite performRunExecution to be more performant
PerformRunExecutionV2:
- Does not create and manage jobRunExecution records
- Does not reimplement retrying, uses graphile worker retrying instead
I’ve kept around PerformRunExecutionV1 so this works when deploying. Definitely needs LOTS of testing
* Fix issues with cached tasks
- Limit the size of the cached tasks sent when executing a run, using the knapsack problem dynamic programming approach
- Actually USE the cached tasks in IO by using the idempotencyKey instead of the task ID
- Remove output from all logs
- Added a stress test job catalog
* Forgot to commit the logger updates
* Never log connectionString
* Login to docker hub to get around rate limits
* Add additional logging to the graphile workers
* Fix the *_ENABLED env vars
* Allow adding and removing jobs to be done from the webapp
* Don’t set the job to failed if it’s being retried
* Deprecated queue options in the job and removed startPosition. Now using the job/env combo as the job queue name
* Dequeung jobs doesn’t check if the runner is initialized
* Fixed issues with retrying a run getting stuck on a cancelled task, and errors from parsing the results of dequeing a job
* Remove queued round robin thing that isn’t used anymore
* Added slack to job catalog
* Better forwards compat
* Added long delay
* Fixed lock file
* chore: make possible to write tests aside with implementations
* test: write getUserPkgManager test TO-DOs
* test: add test to building the path
* test: add tests to manual file checking
* test: add tests to npm_config_user_agent
* Update packages/cli/src/utils/getUserPkgManager.spec.ts
* test: add test to no-duplicated-task-keys rule
* feat: implement no-duplicated-task-keys
* chore: create testing scripts
* refactor: fill in rule meta
* feat: export no-duplicated-task-keys rule
* chore: bump package version to 0.0.1
* chore: create eslint plugin
* feat: create no-duplicated-task-keys rule
* refactor: delete no-duplicated-task-keys from config-custom
* refactor: rename eslint-plugin folder
* feat: cover case from nextjs-example
* feat: cover additional cases from examples/package-tester
* chore: add eslint-plugin on nextjs-example
* feat: add more cases from `nextjs-example`
* revert: rollback changes on eslint-config-custom
* Set version to 2.0.9, inline with other packages
* Create chilly-pianos-try.md
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* FIx: [TRI-1006] New @trigger.dev/cli whoami command.
* revert dev.ts zod schema to original
* Removed telemetry
* remove all telemetry
* Made the clientId optional again
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* chore: run `pnpm install --prefer-frozen-lockfile`
* chore: install `jest` and `ts-jest`
* test: create `jest.config.js`
* chore: install `@types/jest`
* chore: add `jest` on `tsconfig.json` `types` property
* chore: create test script
* test: create example test 🎉🎊🕺🏼
* chore: install `@gmrchk/cli-testing-library`
* chore: override `tsconfig` with `@trigger.dev/tsconfig`
* test: make poc of cli test
* chore: run build before test
* docs: improve comment
* Added a changeset
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* chore: update prisma from version 4.16.0 to 5.1.0
* fixed the ts-errors due to the prisma update
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* Update integrations.mdx
The first sentence in this paragraph for `### API Keys and Tokens` was missing a word or two and it wasn't entirely clear what did the original author of this docs page intended.
I've entered what seems to be the missing context but happy to re-phrase too if another wording makes better sense here.
* Made it clear that API keys are provided by you in your code
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* docs: Update runs.mdx
From what I can tell, it is expected for run functions to return with some sort of payload. Providing an example here as a reference and guideline.
* Made it clear returning data is optional and added some more detail below
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* Added docs images for supabase
* Compressed some existing images
* Improved some of the main quickstart wording
* First draft of the Supabase quickstart
* Tweaks to the Supabase quickstart and the supabase integration docs
---------
Co-authored-by: James Ritchie <james@jamesritchie.co.uk>
* doc: added a new documentation for event filters
* removed typos from the event filter doc and formatted it better.
* made new changes
- moved the eventfilter doc to the guides section
- linked the old eventfilter doc to the new one
* updated the eventfilter doc based on the requested changes
* fix: support express jsonParser middleware if used in the Express app
* Create sixty-windows-run.md
---------
Co-authored-by: Eric Allam <eallam@icloud.com>
* fix: Handle ngrok config upgrade error in createTunnel function
* Improved the output when upgrading the ngrok configuration
* Create three-flies-sneeze.md
---------
Co-authored-by: Eric Allam <eallam@icloud.com>
* feature: initial work for sendgrid integration
* fix: fixed the ts-error and added sendgrid integration to the job-catalogue
* SendGrid added to dependencies
* Made the from email an env var so it can be tested by non-Trigger.dev team members
* Refactor: Modify sendEmail function to return void and remove SendEmailResponse type
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* Create funny-kangaroos-glow.md
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
Co-authored-by: Eric Allam <eallam@icloud.com>
* Only show the Example Jobs list when you have 1 job
* Updated the logic for displaying the different information depending on the no. of jobs you have
* Removed some unnecessary markup
* Clicking on a radio option toggles the content
* Improved the centering of the help panel
* Conetent updates to the 2 onboarding paths
* Added a prompt so you click through to run your job
* More content updates to the help panel
* Only show the prompt if the Job has never been run
* Added back in the help panel which shows the examples table if you have > 0 jobs
* Added a dialog for the I am Stuck button
* Added the new ‘new-next-app’ text for the cli command
* Refactored the ternary logic so it’s simpler
* Removed I’m stuck button and cleaned up imports
* Added in feedback button
* Added margin bottom to the Callout on the Test popover
* WIP adding a new radio button variant that takes an icon
* Added a new step to create a new next app
* The state of the tabs is stored as a URL param
* Small shadow tweak to the side panel
* Added a Discord button to the feedback menu
* Added new icons to the Named icons component
* Added a gradient to the background of the jobs page
* Made the icons take on color outside of component
* Added another NamedIcon for tree
* Fixed number
* Improved some of the typography styles
* Updated the icons
* Fixed issue with radio buttons alignment
* Added a missing step to the new next app onboarding
* Refactored example code and added all the examples to the panel
* Small icon update
* Made the title white again
* Added an icon to the storybook radiogroup
* Added a badges storybook
* Chevron table cell now takes children
* import cleanup
* Changed the background image from an arbirary value to an import
* Added a NEW badge which shows if you have a new job
* Improved the copy on the Examples help panel and updated some of the layout
* Removed defaultOpen on the help panel
* Stop the icons getting smaller
---------
Co-authored-by: D-K-P <dkp.github@pm.me>
* Changed the example job to include a delay
* Improved the example job copy and added ‘in a separate terminal’ to 2.
* Create kind-eggs-pump.md
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* feat: adds a job catalog file when an integration is created via the CLI
* added a changeset
* fix: create-integration CLI throws an error when it tries to install dependencies
* Update getUserPkgManager.ts to main
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* If an endpointId isn’t in the arguments or package, then use the project slug. Don’t ask for it.
* Should await the package artifact detection
* Catch error thrown if there’s no next.config file when detecting the type of Next project
* Create long-carrots-camp.md
* Fix:[TRI-879]-Hides help panel when endpoints exists on the Environments & API Keys page
* fix: adds check for fully configured client
g
---------
Co-authored-by: Crossover <crossover@MacBook-Pro.local>
* Detect presence of a “next” dependency
* Use a strict undefined check instead
* Changeset: Detect Next.js project by looking at dependencies, not next.config.js
* Read a package json file
* First check for next.config file, otherwise use next dependency
* Update changeset description
* Created the sheet
* Started work on the resource route
* Created ValidateCreateEndpointService and the EndpointValidateApi (name TBC)
* The TriggerClient responds with the id
* Tidied some stuff up
* Alternative: EndpointApi doesn’t take endpointSlug. Instead just Ping() does
* Create cool-snakes-deny.md
---------
Co-authored-by: Eric Allam <eallam@icloud.com>
* update cli init to create index file in examples folder
* add patch changeset
* Create silly-baboons-join.md
* remove comment in router file
add comment in jobs index to instruct them to
* rename examplesIndex to examplesIndexFileName
* import jobs module in routeContent for createTriggerPageRoute just as we did for createTriggerAppRoute
---------
Co-authored-by: Matt Aitken <matt@mattaitken.com>
* Basic CLI telemetry
* Telemetry for init command
* Better error handling
* Fix for “Module not found: Can't resolve 'encoding' in” node-fetch warning
* Telemetry for dev and tidied up init
* Minor improvements to the telemetry
* Latest package lock file
* Set the PostHog key to the prod one
* Changesets
* Formatted
* Setup project-wide prettier
* Remove old workspace file
* Remove old debugging directives
* New top-level .prettierignore
* Updated Prettier config settings
* Contrubuting guide: Fix for some bad code blocks
* Added more ignores
* Improved the format script command
* printWidth set to 100
* Formatted entire repo (pnpm run format)
* Changeset should ignore the example projects
* Removed note in Contributing instructions about not adding a changeset for internal
* Renamed @trigger.dev/internal to @trigger.dev/core. Set sdk and internal to be ES2020, so we don’t get errors about private identifiers
* Env vars in nextjs-example use square bracket syntax to avoid Turbo Repo errors
* Set the tsconfigs back for core and sdk
* @examples/nextjs compile error with undefined tasks
* Set the example projects to use ES2015 to avoid private modifier complaints
* package-tester example, which will use built packages
* package-tester package.json
* Created a readme for the package-tester
* Added all the packages to package-tester
* Create .env.local.example and readme instructions
* Added name to the package.json
* Upgraded @types/react and @types/react-dom everywhrre, so we can use server actions
* Upgraded @types/react and @types/react-dom everywhrre, so we can use server actions
* Reworked the react package build, so it generates separate files
* The SDK no longer bundles core
* package-tester setup with a server action and react hooks
* Added new SDK methods with logging
* Working tsup settings for client and server
* Explicit react hooks return types
* Added all the hooks for testing
* Added OpenAI step to the job to check types are still ok in integrations
* Get rid of rogue Changeset ignores
* Changeset: @trigger.dev/core is now a separate package
* Exited prerelease mode, added a changeset
* Changed @next to @latest
* Deleted seed.js, this shouldn’t be committed
* Ignore seed.js
* The webapp was importing @trigger.dev/core with a folder path rather package name…
* More webapp imports instead of @trigger.dev/core were a folder path
* Accidentally edited Stripe internal API url in the comment
* Added “sideEffects”: false so @trigger.dev/core is tree shaken by Remix
* WIP supabase integration
* supabase oauth working
* Supabase database triggers
* Specify postgres:14
* Limit refreshOAuthToken jobs to 10 attempts
* Better displaying types and removing onChange for now
* WIP on the supabase db client
* Finishing the supabase-js integration
* Adding changeset
* Added supabase to the integration catalogs, and added an optional icon to Integrations
* Reworking how we handle types for the triggers (wip)
* Update fully over to the new way to define supabase triggers
* Go back to using the type for the event name
* Add back in the icon to the JobListPresenter since it was moved from the ProjectPresenter
* Remove unused import
* chore(contrib): added a few jobs
* chore(contrib): adds sample jobs for repo setup
* chore(contrib): refactor examples/jobs-starter
* docs(contrib): add steps to add starter jobs
* fix(contrib): typo
* chore(contrib): minor edits
* chore(contrib): update guide and starter code
* chore: use endpointId if package.json has it
* minor
* add changeset
* chore: include changeset
* chore: add proper summary to changeset
* chore: remove redundant changeset file
- Removes the transaction stuff from StartRunService (can try putting it back more granularly)
- Uses $transaction in TestJobService
- Better queue names for the startRun and deliverEvent worker job
CLI: improves how the dev command handles register errors, also doesn’t create a tunnel when hitting local trigger.dev, and improves the dev command output
- Detect middleware usage and warn about how it could conflict with Trigger.dev and with a link to the docs
- Lookup package versions and use the latest versions
- Better error messages when registering an endpoint doesn't work
- Multiple arches in the docker image
- Use the docker@metadata-action github action to create the tags and labels
- Push to Docker Hub and Github Container Repository
- ab512157: Fixed an error message
- 1673d452: Added kv storage to persist data in between runs and between workflows
- 0b67b51a: Fix ESM error by dynamically importing ESM packages (chalk, terminal-link, etc.)
- f39bc44e: SDK now passes through the project ID from the env var
Because they were getting consumed by a subscription to trigger messages in another environment. Fixed this by adding the api key to the subscription name.
ENCRYPTION_KEY=ae13021afef0819c3a307ad487071c06 # Must be a random 16 byte hex string. You can generate an encryption key by running `openssl rand -hex 16` in your terminal
# This is used for logging in via GitHub. You can leave these commented out if you don't want to use GitHub for authentication.
# AUTH_GITHUB_CLIENT_ID=
# AUTH_GITHUB_CLIENT_SECRET=
# Resend is an email service used for signing in to Trigger.dev via a Magic Link.
# Emails will print to the console if you leave these commented out
### Visit https://resend.com, create an account and get your API key. Then insert it below along with your From and Reply To email addresses. Visit https://resend.com/docs for more information.
description:Create a bug report to help us improve
title:"bug: "
labels:["🐞 unconfirmed bug"]
body:
- type:textarea
attributes:
label:Provide environment information
description:|
Run this command in your project root and paste the results:
```bash
npx envinfo --system --binaries
```
validations:
required:true
- type:textarea
attributes:
label:Describe the bug
description:A clear and concise description of the bug, as well as what you expected to happen when encountering it.
validations:
required:true
- type:input
attributes:
label:Reproduction repo
description:If applicable, please provide a link to a reproduction repo or a Stackblitz / CodeSandbox project. Your issue may be closed if this is not provided and we are unable to reproduce the issue. If your bug is a docs issue, link the appropriate page.
validations:
required:true
- type:textarea
attributes:
label:To reproduce
description:Describe how to reproduce your bug. Steps, code snippets, reproduction repos etc.
validations:
required:true
- type:textarea
attributes:
label:Additional information
description:Add any other information related to the bug here, screenshots if applicable.
@@ -4,15 +4,35 @@ Trigger.dev uses [changesets](https://github.com/changesets/changesets) to manag
## Adding a changeset
To add a changeset, use `pnpm run changeset:add` and follow the instructions [here](https://github.com/changesets/changesets/blob/main/docs/adding-a-changeset.md). Please only ever select one of our public packages when adding a changeset, which currently are:
To add a changeset, use `pnpm run changeset:add` and follow the instructions [here](https://github.com/changesets/changesets/blob/main/docs/adding-a-changeset.md). Please only ever select one of our public packages when adding a changeset.
-`@trigger.dev/sdk`
-`@trigger.dev/integrations`
-`@trigger.dev/providers`
## Release instructions
## Release instructions (local only)
Based on the instructions [here](https://github.com/changesets/changesets/blob/main/docs/intro-to-using-changesets.md)
1. Run `pnpm run changeset:version`
2. Run `pnpm run changeset:release`
## Release instructions (CI)
Please follow the best-practice of adding changesets in the same commit as the code making the change with `pnpm run changeset:add`, as it will allow our release.yml CI workflow to function properly:
- Anytime new changesets are added in a commit in the `main` branch, the [release.yml](./.github/workflows/release.yml) workflow will run and will automatically create/update a PR with a fresh run of `pnpm run changeset:version`.
- When the version PR is merged into `main`, the release.yml workflow will automatically run `pnpm run changeset:release` to build and release packages to npm.
## Pre-release instructions
1. Add changesets as usual `pnpm run changeset:add`
2. Switch to pre-release mode by running `pnpm run changeset:next`
3. Create version `pnpm run changeset:version`
4. Release `pnpm run changeset:release`
5. Switch back to normal mode by running `pnpm run changeset:normal`
## Snapshot instructions
!MAKE SURE TO UPDATE THE TAG IN THE INSTRUCTIONS BELOW!
1. Add changesets as usual `pnpm run changeset:add`
2. Create a snapshot version (replace "dev" with your tag) `pnpm exec changeset version --snapshot dev`
3. Build the packages: `pnpm run build --filter "@trigger.dev/*"`
4. Publish the snapshot (replace "dev" with your tag) `pnpm exec changeset publish --no-git-tag --snapshot --tag dev`
Thank you for taking the time to contribute to Trigger.dev. Your involvement is not just welcomed, but we encourage it! 🚀
Please take some time to read this guide to understand contributing best practices for Trigger.dev.
Thank you for helping us make Trigger.dev even better! 🤩
## Developing
The development branch is `main`. This is the branch that all pull
requests should be made against. The changes on the `main`
branch are tagged into a release monthly.
### Prerequisites
- [Node.js](https://nodejs.org/en) version >=16.x
- [pnpm package manager](https://pnpm.io/installation) version 7
- [Docker](https://www.docker.com/get-started/)
### Setup
1. Clone the repo into a public GitHub repository or [fork the repo](https://github.com/triggerdotdev/trigger.dev/fork). If you plan to distribute the code, keep the source code public to comply with the [Apache Licence 2.0](https://github.com/triggerdotdev/trigger.dev/blob/main/LICENSE).
5. Open it and generate a new value for `ENCRYPTION_KEY`:
`ENCRYPTION_KEY` is used to two-way encrypt OAuth access tokens and so you'll probably want to actually generate a unique value, and it must be a random 16 byte hex string. You can generate one with the following command:
```sh
openssl rand -hex 16
```
Feel free to update `SESSION_SECRET` and `MAGIC_LINK_SECRET` as well using the same method.
6. Start Docker. This starts the required services like Postgres. If this is your first time using Docker, consider going through this [guide](DOCKER_INSTALLATION.md)
```
pnpm run docker
```
7. Migrate the database
```
pnpm run db:migrate
```
8. Build the app
```
pnpm run build --filter webapp
```
9. Run the seed script
```
pnpm run db:seed
```
10. Run the app. See the section below.
## Running
1. You can run the app with:
```
pnpm run dev --filter webapp
```
It should run on port `3030`: [http://localhost:3030](http://localhost:3030/)
2. Once the app is running click the magic link button and enter your email.
3. Check your terminal, the magic link email should have printed out as following:
```sh
webapp:dev: Log in to Trigger.dev
webapp:dev:
webapp:dev: Click here to log in with this magic link
2. Change directory to the packages/database folder
```sh
cd packages/database
```
3. Generate the Prisma client
```sh
pnpm run generate
```
The above updates the prisma client generated into node_modules/.prisma/client folder. This helps with typing of relevant prisma models. It ensures typescript
recognizes fields added or removed from a model and type-checks appropriately.
4. Create and apply the migrations
```
pnpm run db:migrate:dev
```
This creates a migration file and executes the migrations against your database and applies changes to the database schema(s)
5. Commit generated migrations as well as changes to the schema.prisma file
6. If you're using VSCode you may need to restart the Typescript server in the webapp to get updated type inference. Open a TypeScript file, then open the Command Palette (View > Command Palette) and run `TypeScript: Restart TS server`.
## Testing CLI changes
To test CLI changes, follow the steps below:
1. Build the CLI and watch for changes
```sh
cd packages/cli
pnpm run dev
```
2. Open a new Terminal window and run the webapp locally and then create a new project in the dashboard. Copy out the dev API key.
3. Create a new temporary Next.js app in references directory
5. Back in the terminal, navigate into the reference, and initialize the CLI. When prompted, select `self-hosted` and enter `localhost:3030` if you are testing against the local instance of Trigger.dev, or you can just use the Trigger.dev cloud. When asked for an API key, use the key you copied earlier.
```sh
cd ./test-cli
pnpm i
pnpm exec trigger-cli init
```
6. If you are just testing the `init` command, you can stop here. If you'd like to test the `dev` command, first start the Next.js app on port 3000:
```sh
pnpm run dev
```
7. Open a new terminal window, and then run the `dev` command like so:
```sh
pnpm exec trigger-cli dev
```
8. Please remember to delete the temporary project you created after you've tested the changes, and before you raise a PR.
## Running end-to-end webapp tests
To run the end-to-end tests, follow the steps below:
1. Set up environment variables (copy example envs into the correct place)
pnpm run build --filter @references/nextjs-test^...
pnpm --filter @trigger.dev/database generate
# Move trigger-cli bin to correct place
pnpm install --frozen-lockfile
# Install playwrite browsers (ONE TIME ONLY)
npx playwright install
```
3. Set up the database
```sh
pnpm run docker
pnpm run db:migrate
pnpm run db:seed
```
4. Run the end-to-end tests
```sh
pnpm run test:e2e
```
### Cleanup
The end-to-end tests use a `setup` and `teardown` script to seed the database with test data. If the test runner doesn't exit cleanly, then the database can be left in a state where the tests can't run because the `setup` script will try to create data that already exists. If this happens, you can manually delete the `users` and `organizations` from the database using prisma studio:
```sh
# With the database running (i.e. pnpm run docker)
pnpm run db:studio
```
## Add sample jobs
The [references/job-catalog](./references/job-catalog/) project defines simple jobs you can get started with.
1. `cd` into `references/job-catalog`
2. Create a `.env` file with the following content,
replacing `<TRIGGER_DEV_API_KEY>` with an actual key:
```env
TRIGGER_API_KEY=[TRIGGER_DEV_API_KEY]
TRIGGER_API_URL=http://localhost:3030
```
`TRIGGER_API_URL` is used to configure the URL for your Trigger.dev instance,
where the jobs will be registered.
3. Run one of the the `job-catalog` files:
```sh
pnpm run events
```
This will open up a local server using `express` on port 8080. Then in a new terminal window you can run the trigger-cli dev command:
```sh
pnpm run dev:trigger
```
See the [Job Catalog](./references/job-catalog/README.md) file for more.
4. Navigate to your trigger.dev instance ([http://localhost:3030](http://localhost:3030/)), to see the jobs.
You can use the test feature to trigger them.
## Making a pull request
**If you get errors, be sure to fix them before committing.**
- Be sure to [check the "Allow edits from maintainers" option](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork) while creating you PR.
- If your PR refers to or fixes an issue, be sure to add `refs #XXX` or `fixes #XXX` to the PR description. Replacing `XXX` with the respective issue number. See more about [Linking a pull request to an issue
We use [changesets](https://github.com/changesets/changesets) to manage our package versions and changelogs. If you've never used changesets before, first read [their guide here](https://github.com/changesets/changesets/blob/main/docs/adding-a-changeset.md).
If you are contributing a change to any packages in this monorepo (anything in either the `/packages` or `/integrations` directories), then you will need to add a changeset to your Pull Requests before they can be merged.
To add a changeset, run the following command in the root of the repo
```sh
pnpm run changeset:add
```
Here's an example of creating a `patch` changeset for the `@trigger.dev/github` and `@trigger.dev/slack` packages (click to view):
You will be prompted to select which packages to include in the changeset. Only select the packages that you have made changes for.
Most of the time the changes you'll make are likely to be categorized as patch releases. If you feel like there is the need for a minor or major release of the package based on the changes being made, add the changeset as such and it will be discussed during PR review.
## Troubleshooting
### EADDRINUSE: address already in use :::3030
When receiving the following error message:
```sh
webapp:dev: Error: listen EADDRINUSE: address already in use :::3030
```
The process running on port `3030` should be destroyed.
1. Get the `PID` of the process running on PORT `3030`
Events that trigger workflows to run. These are sent by the "platform" and read by the Web Socket Servers, which then coordinate with the hosts for running the workflows
#### Run Commands (`persistent://triggerdotdev/workflows/run-commands`)
These are events that come from hosts and are published by the Web Socket Servers, e.g. Sending Integration Requests, Sending Logs, Initializing a Delay
#### Run Command Responses (`persistent://triggerdotdev/workflows/run-command-responses`)
These are events that come from the platform and are read by the Web Socket Servers, to resolve or reject a previous Run Command
1. Ensure you have Homebrew installed by running `which brew` in terminal. If it's not found then you should install it: https://brew.sh/. Run `which brew` again to check it's found. If it's not you may need to [add it your path](https://stackoverflow.com/questions/36657321/after-installing-homebrew-i-get-zsh-command-not-found-brew)
2. Run `brew install libpulsar` to install the C++ libraries that the pulsar-client depends on
3. Make sure you have Python installed on your machine by running `which python3` in terminal.
4. If python isn't found then you should install it: https://www.python.org/downloads/. In a new terminal window run `which python3` again.
5. Run `npm config set python /the/path/from/the/which/python3/command` inserting the path from step 2 or 3
6. Install node-gyp: `npm install -g node-gyp`
7. Make sure you have the Xcode command line tools installed by running `xcode-select --install` from the terminal. If it says they're already installed then you're set.
Next, update the `AUTH_CALLBACK_URL` env var in the `pizzly-server.env` env file with the value provided to the `./scripts/proxy-pizzly.sh` command. Using the example above the `AUTH_CALLBACK_URL` would be `AUTH_CALLBACK_URL=https://dan-pizzly-dev.eu.ngrok.io/oauth/callback`.
If you aren't proxying pizzly according to step 2, then leave the `pizzly-server.env` file empty.
If you are proxying the webapp according to step 2 then in `webapp/.env`, set the `APP_ORIGIN` to the `NGROK_SUBDOMAIN` provided to the `./scripts/proxy-webapp.sh` command, e.g. `APP_ORIGIN=https://dan-trigger-dev.eu.ngrok.io`
4. Start postgresql, pulsar, and pizzly server
```bash
pnpm run docker:db
```
> **Note:** The npm script will complete while Docker sets up the container in the background. Ensure that Docker has finished and your container is running before proceeding.
5. Generate prisma schema
```bash
pnpm run generate
```
6. Run the Prisma migration to the database
```bash
pnpm run db:migrate:deploy
```
7. Run the first build (with dependencies via the `...` option)
```bash
pnpm run build --filter=webapp...
```
**Running simply `pnpm run build` will build everything, including the Remix app.**
Setup a custom launch configuration for the Warp terminal ([docs here](https://docs.warp.dev/features/sessions/launch-configurations)) by copying the `.warp/triggerdotdev.yaml.example` file to `~/.warp/launch_configurations/triggerdotdev.yaml`. Make sure you edit the file and replace `<your-trigger-dev>` and `<your-pizzly-dev>` with your custom ngrok subdomains.
This guide covers installing Docker and Docker Compose. If you're looking for instructions for running Trigger.dev in docker, [see here](https://github.com/triggerdotdev/docker).
## Setting up Docker for the first time.
In the contributing guide of Trigger.dev, there's a section that requires you to start Docker.
If you don't have Docker installed on your machine, you'll run into some complications (errors).
Below are the steps on how you can avoid that.
First you need to setup docker-compose as it is an underlying tool that this command: `pnpm run docker` fires behind the scene.
## Linux
To install Docker Compose on Linux Ubuntu via the terminal, you can follow these steps:
1. Update the package index on your system by running the following command:
```shell
sudo apt update
```
2. Install the required dependencies by running the following command:
```shell
sudo apt install curl
```
3. Download the Docker Compose binary into the `/usr/local/bin` directory using the `curl` command:
4. Set the appropriate permissions to make the `docker-compose` binary executable:
```shell
sudo chmod +x /usr/local/bin/docker-compose
```
5. Verify that Docker Compose has been successfully installed by running the following command:
```shell
docker-compose --version
```
This command should display the version information of Docker Compose without any errors.
After following these steps, you should have Docker Compose installed on your Ubuntu system, and you can use it by running `docker-compose` commands in the terminal.
When you've verified that the `docker-compose` package is installed and you proceed to start Docker with `pnpm run docker`.
You'll probably get an error similar to the one below:
```shell
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
ELIFECYCLE Command failed with exit code 1.
```
The error message suggests that the Docker daemon is not running on your system. The Docker daemon is responsible for managing and running Docker containers.
To resolve this issue, you may need to install Docker properly on your Ubuntu system. Here are the steps to install Docker on Ubuntu:
1. Update the package index on your system by running the following command:
```shell
sudo apt update
```
2. Install the necessary packages to allow apt to use repositories over HTTPS:
7. After the installation is complete, verify that Docker is installed correctly by running the following command:
```shell
docker --version
```
This command should display the version information of Docker without any errors.
Once Docker is installed and verified, you should be able to start the Docker daemon and run the `pnpm run docker` command without encountering any issues.
## Windows
1. Download the Docker Desktop installer from the Docker website: [Docker Desktop for Windows](https://www.docker.com/products/docker-desktop)
2. Run the installer and follow the instructions to install Docker Desktop.
3. After installation, Docker Desktop should be running automatically.
## macOS
1. Download the Docker Desktop installer from the Docker website: [Docker Desktop for Mac](https://www.docker.com/products/docker-desktop)
2. Run the installer and follow the instructions to install Docker Desktop.
3. After installation, Docker Desktop should be running automatically.
Please note that the instructions provided above are for the most common scenarios. For specific versions or different distributions, it's always a good idea to consult the official Docker documentation for the respective operating systems.
Create long-running jobs directly in your codebase with features like API integrations, webhooks, scheduling and delays.
# ⚙️ Effortless automation built for developers
## Long running Jobs on serverless
Trigger workflows from APIs, on a schedule, or on demand. API calls are easy with authentication handled for you. Add durable delays that survive server restarts.
Reliably run jobs and don’t worry about function timeouts, we handle those for you.
Trigger.dev is code-first so you can create workflows where they belong: in your codebase. Version control, localhost, test, review, and deploy like you're used to.
Create Jobs where they belong: in your codebase. Version control, localhost, test, review, and deploy like you're already used to.
## Secure by design
Your workflows run on your servers, not ours. We only receive the data you choose to send to us.
We only receive Triggers and the data you choose to send to us. You can even completely self-host the entire platform.
## Don't worry about deployment
# Hundreds of Integrations
Just use our SDK to write Jobs in your codebase. There's nothing extra to deploy and no CI to configure, your Jobs just connect to our cloud. Or you can always self-host.
Subscribe to API changes and make requests, we’ll handle authentication for you.
## Full visibility of every job run
View every Task in every Run so you can tell exactly what happened.
Easily integrate with hundreds of third-party APIs – including your own. Use API keys (which never leave your server) or let us handle OAuth for you. Install our integration packages and easily subscribe to webhooks and perform common tasks, or you can easily use your existing favorite Node.JS SDKs and get resumability and idempotency through our `runTask` function.
Triggered when a GitHub issue is created or updated. Query your database to map GitHub user ids to Linear user ids. Then create or update Linear issues.",
## Our progress
```Typescript
We’re building the most comprehensive and easy-to-use background jobs framework for developers.
We provide an official trigger.dev docker image you can use to easily self-host the platform. We're working on more extensive guides but we currently provide a [Fly.io example repository](https://github.com/triggerdotdev/fly.io) with instructions in the README for deploying and using a self-hosted instance of Trigger.dev on Fly.io.
Triggered on demand by your other code when a user is created. We wait for 3 hours then send a follow-up email if the user hasn’t completed onboarding yet.
Triggered when an Intercom incident happens. We create a Linear issue, send a Slack message and, if it’s an urgent incident, we alert whoever is on call.
Write workflows by creating triggers directly in your code. These can be 3rd-party integrations, custom events or on a schedule.
## **2. Connect**
When your server runs, your workflow will be registered and you can authenticate with any APIs you’re using.
## **3. Test**
When your server runs, your workflow will be registered and you can authenticate with any APIs you’re using.
## **3. Deploy**
Deploy your new workflow as you would any other code commit and inspect each workflow run in real time.
# ✅ We ❤️ Open Source!
You’ll always be able to host and run Trigger.dev yourself.
We've also created [JSON Hero](https://github.com/triggerdotdev/jsonhero-web), an open source JSON viewer used by around 55,000 developers per month.
# 🙋 FAQs
<details><summary> Does my data get sent to your servers?</summary><br>
Only what you choose to send. The main body of your workflow code runs on your infrastructure.
For example when you do a database query, that never touches us.
Data we will receive (and store to display on the Runs page in your dashboard):
- Any data that triggers the start of a workflow
- Any data you pass to one of our API integrations • Any data you choose to log using our logging function
</details>
<details><summary> How is this different to Zapier, Pipedream etc?</summary><br>
Trigger.dev is a code-first workflow tool that lets you create workflows directly in your code, rather than using a UI builder like Zapier. This means you can stay in your own IDE and keep your internal data secure.
</details>
<details><summary>How long does this take to set up?</summary><br>
Setting up Trigger.dev is simple and takes 2 minutes. Install our SDK to get started and check out the Getting Started documentation to start creating your first workflow.
</details>
<details><summary>Can I use version control or roll-backs?</summary><br>
Yes. You create workflows directly in your own code so it’s version controlled with everything else.
</details>
<details><summary>How long does it take to code up a workflow?</summary><br>
A simple workflow triggering two events from different services will take about 5 minutes to create.
</details>
<details><summary>Do you have all the integrations I need?</summary><br>
Probably. Trigger.dev includes over 100 integrations including the most popular services. If you need a specific service that’s not available, you can request it, or create it yourself. We’re open source, so create an issue or Pull Request.
</details>
<details><summary>Can I build complex workflows?</summary><br>
Yes. There’s no limit to the complexity on workflows you can create. Workflows are created in code so you can write conditional, looping, branching or time delayed logic.
</details>
<details><summary> Can I run Trigger.dev locally?</summary><br>
Yes. Workflows are created in your code locally and, unlike webhooks, you don’t need to use tunneling to receive triggers.
</details>
<details><summary>How does the pricing model work?</summary><br>
Our hosted product gives you free runs each month, after that you will need to select a paid tier. You can also self-host, view the open source repository for instructions.
</details>
<details><summary>Is Trigger.dev open source?</summary><br>
Yes, Trigger.dev is open source. We are strong supporters of open source software, and our first product, [jsonhero.io](https://jsonhero.io), has a thriving open source community. Trigger.dev follows in that tradition.
</details>
<details><summary>Is Trigger.dev a no/low-code tool?</summary><br>
No. Trigger.dev is designed for developers who want to create workflows directly in code, without using a UI builder like Zapier. This allows developers to stay in their familiar development environment and customise their workflows with code.
</details>
<details><summary>What languages / frameworks do you support?</summary><br>
Currently there is support for Node.js. More frameworks will be added soon.
</details>
<details><summary>Can I use an API which doesn’t have webhooks?</summary><br>
Yes. You can use a polling trigger to subscribe is no webhook exists.
</details>
<details><summary>Can non-coders use this product?</summary><br>
Developers will need to create workflows. Anyone on the team can monitor running workflows in the Trigger dashboard.
</details>
---
If you have any other questions about Trigger.dev, [drop us an email](mailto:hello@trigger.dev), and one of the founders will get back to you.
To setup and develop locally or contribute to the open source project, follow our [development guide](./CONTRIBUTING.md).
description: "A generic fetch function that can be used to call any HTTP endpoint"
---
## Usage
A `fetch` function is available to use inside a `Trigger.run` function through the `context` argument, and should be familiar for anyone who has used the standard [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API, with a few modifications.
Notice the first parameter to `fetch` is a `key` that is used to identify this call to fetch to support resumability. Please see the [Resumability](/guides/resumability) guide for more information.
You can also import `fetch` and use it outside of a `Trigger.run` function:
Now you can use the exported `httpBinGet` function inside your `Trigger.run` function:
```ts
import { Trigger } from "@trigger.dev/sdk";
import { httpBinGet } from "./httpBin";
new Trigger({
id: "fetch-example",
name: "Fetch Example",
on: customEvent({
name: "example.fetch",
}),
run: async (event, ctx) => {
await httpBinGet();
},
}).listen();
```
This is useful if you want to wrap `fetch` to provide an SDK like experience inside your workflows.
<Warning>
Calling `fetch` when not inside of a workflow run will result in a thrown
Error.
</Warning>
## Response
<Info>
Non-ok responses will currently halt the progress of a run, so `response.ok`
is always `true`
</Info>
The return value of `fetch` is a similar to a normal fetch response, but we will automatically parse the response body as JSON and provide it as `body`, like so:
It's okay to not be comprehensive with the schema, as long as the response body matches the schema, it will be valid. Do note that any properties not included in the schema will be excluded, unless you use `.passthrough()`:
console.log(response.body); // Includes url, origin, headers, and everything else
```
<Note>
The fetch function currently only supports JSON request and response bodies.
</Note>
## Secret values
If you are using a header with a secret value, you can use our `secureString` [tagged template](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates) to ensure that the value is not logged in the trigger.dev logs:
```ts
import { Trigger, secureString } from "@trigger.dev/sdk";
By default, we will retry a failed request up to 10 times if it has one of the following status codes: `408`, `429`, `500`, `502`, `503`, `504`. You can override this behavior by providing a `retry` option:
Currently, we don't have anything special for loops or conditionals. You can just write plain-old TypeScript code and it will Just Work™.
## Loops
When you perform an action (sendEvent, delays, etc.) inside of a loop, make sure to create unique keys for each action to make sure that your workflows are [Resumable](/guides/resumability):
```ts
for (let i = 0; i < 10; i++) {
await ctx.waitFor(`Wait ${i}`, { seconds: 30 });
await slack.postMessage(`⭐️ New Star ${i}`, {
channelName: "github-stars",
text: `@${starredBy} just starred ${repoName}!`,
});
}
```
## Parallel Execution
You can run actions in parallel using `Promise.all`, like so:
```ts
await Promise.all(
messages.map((message) =>
slack.postMessage(message.id, {
channelName: "github-stars",
text: message.text,
})
)
);
```
## Conditionals
You can use `if` statements to conditionally execute code, just like normal code:
```ts
if (ctx.event.payload.action === "opened") {
await slack.postMessage("New Issue", {
channelName: "github-issues",
text: `@${ctx.event.payload.sender.login} just opened an issue!`,
- `@trigger.dev/sdk` is required to use Trigger.dev, it allows you to run workflows.
- `@trigger.dev/integrations` allows you to easily subscribe to webhooks and use API calls from popular services.
- `zod` is used to define schemas (the expected shape of an object).
## 2. Sign in to your Trigger.dev dashboard
Go to [trigger.dev](https://app.trigger.dev) and sign up or login to your account.
## 3. Get your API keys
In the bottom-left corner of an Organization page you can find your API keys.
## 4. Creating your first workflow
Workflows are triggered by events. In this example, we have defined a custom event called `user.created`. We support many different types of events including webhooks, scheduled, and more coming soon.
```ts first-workflow.ts
import { Trigger, customEvent } from "@trigger.dev/sdk";
import { slack } from "@trigger.dev/integrations";
import { z } from "zod";
const postMessage = new Trigger({
id: "new-user",
name: "New user slack message",
apiKey: "<your_api_key>",
logLevel: "info",
on: customEvent({
name: "user.created",
schema: z.object({
name: z.string(),
email: z.string(),
paidPlan: z.boolean(),
}),
}),
run: async (event, ctx) => {
await ctx.logger.info("This log will appear on the Trigger.dev run page");
//send a message to the #new-users Slack channel with user details
text: `New user: ${event.name} (${event.email}) signed up. ${
event.paidPlan ? "They are paying" : "They are on the free plan"
}.`,
});
return response.message;
},
});
//this workflow will now connect and start listening for events
postMessage.listen();
```
You'll notice that when we subscribe to the custom event we have to say the name of the event and provide a schema. Schemas are created using Zod. In this case events must send an object that has `name`, `email`, and `paidPlan`.
<Note>
If the event is triggered with an object that doesn't match this schema, the
workflow won't run.
</Note>
<Note>
Above we set the API key inside the Trigger object. We recommend instead that
you add an environment variable called `TRIGGER_API_KEY`. That way you can use
your development API key locally and the production one when you deploy.
</Note>
## 6. Run your web server
Run your server how you normally would, e.g. `npm run dev`. This will connect your workflow to Trigger.dev, so we can start sending you events. You should see some log messages in your server console (tip: you can turn these off by removing the `logLevel: "info"` from the code above).
## 5. Testing your workflow from the dashboard
Now that the workflow is connected to Trigger.dev we need to trigger it. You can easily test your workflow from [your Trigger.dev dashboard](https://app.trigger.dev).
On the organization page you should see that the Workflow has now appeared (you may need to refresh the page from last time).
Move to the "New user slack message" and you will see the workflow page. There have been no runs yet.
Move to the "Test" page and input a valid test event, remember the workflow expects a name, email and paidPlan. You can copy this:
```json
{
"name": "Rick Astley",
"email": "nevergonn@giveyou.up",
"paidPlan": true
}
```
Hit the "Run test" button and it will take us to our first run 🚀!
## 6. The run page
All of the steps in a workflow, including the initial event, can be viewed in detail. You will need to refresh the page if it's running to see it move between steps.
But there's a problem, we've used Slack in our code and we haven't authenticated.
## 7. Authenticating with Slack
When a workflow step uses an API integration that you haven't already authenticated with, it will pause until you've authenticated.
Simply click the "Connect to Slack" button and sign-in with your desired Slack workspace. As soon as you do, the workflow will pick up where it left off.
Test complete!
## 8. Triggering this workflow from code
As this workflow uses a custom event, we need to manually trigger it from our code. Anywhere in your code you can do this:
```ts
import { sendEvent } from "@trigger.dev/sdk";
/*
...your other code
*/
await sendEvent({
apiKey: "<my_api_key>",
event: {
name: "Eleven",
email: "jane@hawksmoorhigh.edu",
paidPlan: true,
},
});
```
When you run your server and this code executes, it will trigger the workflow. You will see this in the run list on your workflow page.
## Next steps
<Card
title="Join the communty"
icon="discord"
href="https://discord.gg/nkqV9xBYWy"
>
Meet other users, get help and product updates. We will respond to all
messages and will help with any issues.
</Card>
There are many things we didn't cover here, including Webhook and Scheduled triggers. Below are a some more features to explore:
description: "How to build an event driven architecture using Trigger.dev"
---
## Event-driven Patterns in Trigger.dev
### Claim check pattern
Inspired by [this post](https://serverlessland.com/event-driven-architecture/visuals/claim-check-pattern) by [@boyney123](https://twitter.com/boyney123), here is how you could implement the claim check pattern using Trigger.dev:
```ts
import { Trigger } from "@trigger.dev/sdk";
import { github } from "@trigger.dev/integrations";
import { db } from "./db.server";
new Trigger({
id: "issue-producer",
on: github.events.issueEvent({
repo: "triggerdotdev/trigger.dev",
}),
run: async (event, ctx) => {
// 1. Store the event in a database (e.g. MongoDB, DynamoDB, etc.)
const id = await db.insert(ctx.id, event);
// 2. Send a new event with the id of the stored event
await ctx.sendEvent("📧 Send Event", {
name: "github.issue",
payload: {
id,
action: event.payload.action,
},
});
},
}).listen();
```
The above workflow will store any issue events from the trigger.dev repo in a database. Then, it will send a new event with the name `github.issue` and the id and action of the stored event. This event can then trigger another workflow and be used to retrieve the original event from the database:
```ts
import { Trigger, customEvent } from "@trigger.dev/sdk";
import { db } from "./db.server";
import { z } from "zod";
new Trigger({
id: "opened-issue-consumer",
on: customEvent({
name: "github.issue",
filter: {
action: ["opened"],
}
schema: z.object({ id: z.string() }),
}),
run: async (event, ctx) => {
// 3. Retrieve the event from the database
const event = await db.get(ctx.id);
// 4. Do something with the event
},
}).listen();
```
As you can see above we filtered the event to only trigger when the action is `opened`. This is because we only want to do something when an issue is opened. We also used a schema to validate the event payload (which in this pattern is pretty simple).
description: "Event filters are used to filter events based on their attributes."
---
Event filters are used to filter events based on their attributes in the [customEvent](/reference/custom-event) and [webhookEvent](/reference/webhook-event) triggers.
They are declarative pattern-matching rules, modeled after [AWS EventBridge patterns](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html).
Given the following custom event payload:
```json
{
{
"uid": "jexAgaeJFJsrGfans1pxqm",
"type": "15 Min Meeting",
"price": 0,
"title": "15 Min Meeting between Eric Allam and John Doe",
"length": 15,
"status": "ACCEPTED",
"endTime": "2023-01-25T16:00:00Z",
"bookingId": 198052,
"organizer": {
"id": 32794,
"name": "Eric Allam",
"email": "eric@trigger.dev",
"language": { "locale": "en" },
"timeZone": "Europe/London"
},
}
}
```
The following event filter would match the event:
```json
{
"type": ["15 Min Meeting"],
"status": ["ACCEPTED", "REJECTED"],
"organizer": {
"name": ["Eric Allam"]
}
}
```
For an event pattern to match an event, the event must contain all the field names listed in the event pattern. The field names must also appear in the event with the same nesting structure.
The value of each field name in the event pattern must be an array of strings, numbers, or booleans. The event pattern matches the event if the value of the field name in the event is equal to any of the values in the array.
Effectively, each array is an OR condition, and the entire event pattern is an AND condition.
So the above event filter will match because `status == "ACCEPTED"`, and it would also match if `status == "REJECTED"`.
description: "Understand how keys work to ensure resumability of long-running workflows in Trigger.dev"
---
## Intro
In this article, we'll cover how Trigger.dev handles resumability of long-running workflows. We'll also cover how to use keys to ensure that your workflows are resumable.
## What is resumability?
Resumability is the ability of a workflow run to continue from where it left off after a failure or interruption. For example, if a workflow run is interrupted due to a network failure, it should be able to resume from where it left off when the network is back up.
We accomplish this by storing the state of the workflow run in a database, and when a workflow run is resumed we will call the `Trigger.run` function again.
We use step "keys" to determine which steps have already been executed. If a step has already been executed, we will skip it and move on to the next step.
## How to use keys
Like we mentioned above, we use step keys to determine which steps have already been executed. They are defined by you inside your `Trigger.run` function, for example when you call `slack.postMessage`:
```ts
await slack.postMessage("⭐️ New Star", {
channelName: "github-stars",
text: `@${starredBy} just starred ${repoName}!`,
});
```
In this example, the key is the string `"⭐️ New Star"`. This means that if the workflow is interrupted and then resumed, the `slack.postMessage` step will be skipped because it has already been executed.
If you make multiple calls to `slack.postMessage`, you should use different keys for each call. For example:
```ts
await slack.postMessage("⭐️ New Star", {
channelName: "github-stars",
text: `@${starredBy} just starred ${repoName}!`,
});
await slack.postMessage("🚨 Critical Issue", {
channelName: "critical-issues",
text: `@${assignee} just opened a critical issue in ${repoName}!`,
});
```
If you are calling a step multiple times with the same key, it will only be executed once. For example, if you call `slack.postMessage` with the key `"⭐️ New Star"` twice, it will only be executed once.
## How to use keys with loops
If you are using a loop, you should use the loop index as the key. For example:
```ts
for (let i = 0; i < 10; i++) {
await ctx.waitFor(`Wait ${i}`, { seconds: 30 });
await slack.postMessage(`⭐️ New Star ${i}`, {
channelName: "github-stars",
text: `@${starredBy} just starred ${repoName}!`,
});
}
```
## When to use keys
The following functions in Trigger.dev require a `key` parameter:
- Integration actions (e.g. `slack.postMessage`)
- [delays](/functions/delays)
- [sendEvent](/functions/send-event)
- [fetch](/functions/fetch)
[Logging](/functions/logging) does not require a key, as we are currently using the log message as the key.
We will show each API as a subpage. Each API page will break down all the functions available for each API. It will also link to the relevant sample projects.
<CardGroup>
<Card
title="GitHub"
icon="rectangle-terminal"
href="/integrations/apis/github"
></Card>
<Card
title="Shopify"
icon="rectangle-terminal"
href="/integrations/apis/shopify"
></Card>
<Card
title="Slack"
icon="rectangle-terminal"
href="/integrations/apis/slack"
></Card>
</CardGroup>
### Do you need a specific integration?
If so, [let us know](mailto:hello@trigger.dev) and we'll build it for
Send email using Resend.com, which supports sending emails using React, HTML, and plain text. Resend.com is currently in private beta but you can request early access [here](https://resend.com/).
<Note>
If you'd like to render emails using React, please see the [React.email
Publish slack messages to a public or private channel in your Slack Workspace as the Trigger.dev Slack bot. If you need to publish messages to your customer's Slack channels, consider using [Incoming Webhooks](https://api.slack.com/messaging/webhooks) and our [fetch](/functions/fetch) function.
description: "Custom event triggers allow you to run workflows from your own code (or your other workflows)"
---
[Send an event](/functions/send-event) and any workflows that subscribe to that custom event will get triggered.
## Name and Schemas
### Name
Custom event triggers have a `name`. They will only get triggered when a custom event with that name are sent.
### Schema
Custom event triggers take a [Zod](https://github.com/colinhacks/zod) schema. This is used to validate the data that is sent with the event. If the data does not match the schema, the workflow will not run.
It also means that inside your run function the event param will be typed correctly. We use [Zod](https://github.com/colinhacks/zod#installation) for our schemas – it's a fantastic library that allows you to define schemas in a very simple way.
You can always start out by using `z.any()` as your schema, and then later on you can add more strict validation. See our [Zod guide](/guides/zod) for more information.
## Filters
You can also add filters to your custom event triggers. This allows you to filter out events that you don't want to run your workflow for.
```ts
new Trigger({
id: "new-user-slack",
name: "New user slack message",
on: customEvent({
name: "user.created",
schema: z.object({
name: z.string(),
email: z.string(),
paidPlan: z.boolean(),
}),
filter: {
//only run the workflow if the user is paying
paidPlan: [true],
},
}),
//this function is run when the custom event is received
run: async (event, ctx) => {
//send a message to the #new-users Slack channel with user details
description: "Run a workflow on a recurring schedule"
---
See the [reference](/reference/schedule-event) for more details.
## Examples
### Every 5 minutes
This job will run every 5 minutes, starting 5 minutes after this code is first run on your server (that includes running locally).
```ts
import { Trigger, scheduleEvent } from "@trigger.dev/sdk";
new Trigger({
id: "scheduled-workflow",
name: "Scheduled Workflow",
apiKey: "<your_api_key>",
on: scheduleEvent({ rateOf: { minutes: 5 } }),
run: async (event, ctx) => {
await ctx.logger.info("Received the scheduled event", {
event,
wallTime: new Date(),
});
return { foo: "bar" };
},
}).listen();
```
### Using CRON syntax
This job will run at 2:30pm every Monday. You can get help with [CRON syntax](https://crontab.guru/).
```ts
import { Trigger, scheduleEvent } from "@trigger.dev/sdk";
new Trigger({
id: "cron-scheduled-workflow",
name: "Cron Scheduled Workflow",
apiKey: "<your_api_key>",
on: scheduleEvent({ cron: "30 14 * * 1" }),
run: async (event, ctx) => {
await ctx.logger.info("Received the cron scheduled event", {
event,
wallTime: new Date(),
});
return { foo: "bar" };
},
}).listen();
```
## Preventing late runs
To prevent a scheduled trigger from running late, you can set a `triggerTTL` option when creating the `Trigger`, like so:
```ts
new Trigger({
id: "scheduled-workflow",
name: "Scheduled Workflow",
apiKey: "<your_api_key>",
on: scheduleEvent({ rateOf: { minutes: 5 } }),
triggerTTL: 300,
run: async (event, ctx) => {
await ctx.logger.info("Received the scheduled event", {
event,
wallTime: new Date(),
});
return { foo: "bar" };
},
}).listen();
```
This will prevent the trigger from running if it is running more than `300` seconds behind, which can happen if the server running your `Trigger` code goes down or is otherwise unavailable.
This is especially useful for scheduled triggers that run on a very short interval, like every minute, so you don't get a backlog of runs that all run at once when the server comes back online.
<Tip>
Set your `triggerTTL` to the same time (or double) as the rateOf the trigger.
description: "Webhooks allow you to subscribe to events from APIs you use."
---
Webhooks are a crucial part of API development, allowing for real-time reactions to various events across different systems, such as when a Stripe Payment is made, or when a GitHub issue is created.
## Advantages of using Trigger.dev for webhooks
Webhooks can be difficult to work with, especially when developing locally. We make them far easier to use with our [integrations](/integrations/apis).
- You don't need to register/unregister for webhooks, we do it for you
- They work locally during development without needing to use tunnels (e.g. Ngrok)
- We receive the webhook, then keep trying to send it to you until you receive it. If your server goes down, no problem.
## Usage
There are two ways to use webhooks with Trigger.dev:
1. Use one of our built-in integrations, such as [GitHub](/integrations/github). We'll take care of registering the webhook for you.
2. Use our [webhookEvent](/reference/webhook-event) function to create a webhook subscription and you'll register the webhook yourself.
## Webhook integrations
We currently have built in integrations for the following webhooks:
- [GitHub](/integrations/apis/github)
Please [join our discord community](https://discord.gg/kA47vcd8P6) and let us know which integration you'd like us to add.
We've documented all the support webhooks for each integration in the sidebar, for example the GitHub [newStarEvent](/integrations/apis/github/events/new-star) webhook:
```ts
import { github } from "@trigger.dev/integrations";
new Trigger({
id: "demo",
on: github.events.newStarEvent({
repo: "triggerdotdev/trigger.dev",
}),
run: async (event, ctx) => {},
}).listen();
```
Once you've connected to Trigger.dev, and authorized your GitHub account, we'll go ahead and register the webhook in the repository you've specified and start triggering your `Trigger.run` function when new stars roll in.
## Manual Webhooks
If we haven't built out the integration you need, you can use our `webhookEvent` function to create a webhook subscription. You'll need to register the webhook yourself, but we'll take care of the rest. Here's an example for triggering events when a new booking happens in [Cal.com](https://cal.com):
```ts
new Trigger({
id: "caldotcom-to-slack",
name: "Cal.com To Slack",
on: webhookEvent({
service: "cal.com",
eventName: "BOOKING_CREATED",
filter: {
triggerEvent: ["BOOKING_CREATED"],
},
schema: z.any(),
verifyPayload: {
enabled: true,
header: "X-Cal-Signature-256",
},
}),
run: async (event, ctx) => {},
}).listen();
```
For more information on the various options for `webhookEvent`, see the [webhookEvent reference](/reference/webhook-event).
Once you connect to Trigger.dev, we will display the URL and (optionally) the secret you need to register with the webhook provider on the workflow overview page:
Copy the URL and secret, and register the webhook with the provider (in this case, Cal.com). Once you've done that, we'll start triggering your `Trigger.run` function when the webhook fires.
## Examples
<CodeGroup>
```ts Github
import { Trigger } from "@trigger.dev/sdk";
import { github, slack } from "@trigger.dev/integrations";
new Trigger({
id: "escalate-critical-issues",
name: "Posts to Slack when GitHub Issue created or modified",
apiKey: "<my_api_key>",
//this is the webhook subscription
on: github.events.issueEvent({
repo: "my-github-org/my-github-repo",
}),
//this function is run when the webhook fires
run: async (event, ctx) => {
if (event.action === "labeled") {
await ctx.logger.info(
`The issue ${event.issue.title} was labeled ${event.label.name}`
);
if (event.label.name === "critical") {
await slack.postMessage("send-to-slack", {
channel: "serious-issues",
text: `Critical issue: ${event.issue.title} was labeled ${event.label.name}`,
Trigger.dev is an open source platform that enables developers to create event-driven background tasks directly in their code. Build, test and run workflows locally and subscribe to webhooks, schedule jobs, run background jobs and add long delays easily and reliably.
Workflows live in your codebase so you can use your existing types, functions, version control and IDE. They are triggered by us but run on your server so your private data is never exposed.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
mnmt7
