Files
triggerdotdev--trigger.dev/docs/github-actions.mdx
T
Eric Allam cf13fbdf32 Updating docs for the move from beta -> latest (with new build system) (#1299)
* Add triggerAndWait().unwrap() to more easily get at the output or throw the subtask error

* Add taskId and runId to SubtaskUnwrapError

* WIP docs update beta -> latest

* trigger.dev init now adds @trigger.dev/build to devDependencies

* How it works doc

* Restructure some docs and update the cli commands

* Config file docs, plus aptGet and ffmpeg extensions

* Update to latest from beta docs

* Add runtime to templates

* Add --runtime option to the init CLI command

* A bunch more doc updates after feedback

* Document triggerAndWait with unwrap and result types

* beta -> latest in the webapp

* CLI update check no longer references beta

* Add major release

* Leave changeset beta, back to normal package release

* Fixed default dirs option in init command

* exclude windows-yarn variation of cli e2e tests because it’s buggy

* Remove cache to try and fix yarn e2e test workflow errors
2024-09-16 15:30:32 +01:00

125 lines
3.4 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@latest 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@latest 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. ![Add TRIGGER_ACCESS_TOKEN
in GitHub](/images/github-access-token.png)
</Step>
</Steps>
## Version pinning
The CLI and `@trigger.dev/*` package versions need to be in sync with the `trigger.dev` CLI, 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 deploy",
"deploy:trigger": "npx trigger.dev@3.0.0 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.