James Ritchie
0d4e3e70c1
* tasks no longer inside a group in the side menu (and added “cron”) * Delay using a timezone * Added React Not Defined error to the troubleshooting page * Improved the React common problem * Link to v2 docs * New Development section and entry in Common Problems * Concurrently running the terminal * Fixed the .env weirdness * Added section on creating PATs for Github actions * Improved the Machine spec and limits page * Quick start steps now have nice images * Added a diagram for the lifecycle functions * Added note about onFailure * CRON -> cron/Cron * Updated the cli-dev steps for the concurrently package * Fixed capital letter * Updated diagram text * Removed dead page
118 lines
3.3 KiB
Plaintext
118 lines
3.3 KiB
Plaintext
---
|
|
title: "GitHub Actions"
|
|
description: "You can easily deploy your tasks with GitHub actions."
|
|
---
|
|
|
|
This simple GitHub action file will deploy your Trigger.dev tasks when new code is pushed to the `main` branch and the `trigger` directory has changes in it.
|
|
|
|
<Warning>
|
|
The deploy step will fail if any version mismatches are detected. Please see the [version
|
|
pinning](/github-actions#version-pinning) section for more details.
|
|
</Warning>
|
|
|
|
<CodeGroup>
|
|
|
|
```yaml .github/workflows/release-trigger-prod.yml
|
|
name: Deploy to Trigger.dev (prod)
|
|
|
|
on:
|
|
push:
|
|
branches:
|
|
- main
|
|
paths:
|
|
- "trigger/**"
|
|
|
|
jobs:
|
|
deploy:
|
|
runs-on: ubuntu-latest
|
|
|
|
steps:
|
|
- uses: actions/checkout@v2
|
|
|
|
- name: Use Node.js 20.x
|
|
uses: actions/setup-node@v4
|
|
with:
|
|
node-version: "20.x"
|
|
|
|
- name: Install dependencies
|
|
run: npm install
|
|
|
|
- name: 🚀 Deploy Trigger.dev
|
|
env:
|
|
TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
|
|
run: |
|
|
npx trigger.dev@beta deploy
|
|
```
|
|
|
|
```yaml .github/workflows/release-trigger-staging.yml
|
|
name: Deploy to Trigger.dev (staging)
|
|
|
|
# Requires manually calling the workflow from a branch / commit to deploy to staging
|
|
on:
|
|
workflow_dispatch:
|
|
|
|
jobs:
|
|
deploy:
|
|
runs-on: ubuntu-latest
|
|
|
|
steps:
|
|
- uses: actions/checkout@v2
|
|
|
|
- name: Use Node.js 20.x
|
|
uses: actions/setup-node@v4
|
|
with:
|
|
node-version: "20.x"
|
|
|
|
- name: Install dependencies
|
|
run: npm install
|
|
|
|
- name: 🚀 Deploy Trigger.dev
|
|
env:
|
|
TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
|
|
run: |
|
|
npx trigger.dev@beta deploy --env staging
|
|
```
|
|
|
|
</CodeGroup>
|
|
|
|
If you already have a GitHub action file, you can just add the final step "🚀 Deploy Trigger.dev" to your existing file.
|
|
|
|
### Creating a Personal Access Token
|
|
|
|
<Steps>
|
|
|
|
<Step title="Create a new access token">Go to your profile page and click on the ["Personal Access Tokens"](https://cloud.trigger.dev/account/tokens) tab.</Step>
|
|
|
|
<Step title="Go to your repository on GitHub.">Click on 'Settings' -> 'Secrets and variables' -> 'Actions' -> 'New repository secret'</Step>
|
|
|
|
<Step title="Add the TRIGGER_ACCESS_TOKEN">Add the name `TRIGGER_ACCESS_TOKEN` and the value of your access token. </Step>
|
|
|
|
</Steps>
|
|
|
|
|
|
|
|
## Version pinning
|
|
|
|
The CLI and `@trigger.dev/*` package versions need to be in sync, otherwise there will be errors and unpredictable behavior. Hence, the `deploy` command will automatically fail during CI on any version mismatches.
|
|
Tip: add the deploy command to your `package.json` file to keep versions managed in the same place. For example:
|
|
|
|
```json
|
|
{
|
|
"scripts": {
|
|
"deploy:trigger-prod": "npx trigger.dev@3.0.0-beta.34 deploy",
|
|
"deploy:trigger": "npx trigger.dev@3.0.0-beta.34 deploy --env staging"
|
|
}
|
|
}
|
|
```
|
|
Your workflow file will follow the version specified in the `package.json` script, like so:
|
|
|
|
```yaml .github/workflows/release-trigger.yml
|
|
- name: 🚀 Deploy Trigger.dev
|
|
env:
|
|
TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
|
|
run: |
|
|
npm run deploy:trigger
|
|
```
|
|
|
|
You should use the version you run locally during dev and manual deploy. The current version is displayed in the banner, but you can also check it by appending `--version` to any command.
|