Matt Aitken
de302858f8
* Started building out the docs navigation * Drafted out a lot of the docs pages. With just titles and descriptions with a coming soon message for now. * A ton more scaffolded pages with titles, descriptions, coming soon/incomplete docs messages * Created the remaining page stubs * Introduction page improvements * Lots of docs changes, mostly the task overview page * Moved some bits around * Task overview fleshed out * Triggering docs page * Regular task page * CLi dev docs * Docs for debugging locally * Environment variables docs * Added env var images * Deployment guides * Updated the title of “Integrations” to “Deployment integrations” to make it less confusing * Lots more docs pages * Changed the language to JavaScript * Fixed typos about queues and added a simple code sample * Moved the local debugger docs into the CLI dev page * Added the CLI deploy options * Delete the local debugger page * Updated the logging page with structured logging * Added the new CLI deploy options * Change to h4 for one of the options * Errors page * WIP on retrying * Retrying guide * Wait docs pages * Queuing docs simplified, partial written * Queuing and concurrency docs * Run tests docs * New combined error and retrying page * Errors and retrying page updated * More docs * Added a possible configurations coming soon table * Created a limits page * Added warnings about how you need to get early access * Minor fixes for the docs
57 lines
2.7 KiB
Plaintext
57 lines
2.7 KiB
Plaintext
---
|
|
title: "Versioning"
|
|
description: "We use atomic versioning to ensure that started tasks are not affected by changes to the task code."
|
|
---
|
|
|
|
A version is a bundle of tasks at a certain point in time.
|
|
|
|
## Version identifiers
|
|
|
|
Version identifiers look like this:
|
|
|
|
- `20240313.1` - March 13th, 2024, version 1
|
|
- `20240313.2` - March 13th, 2024, version 2
|
|
- `20240314.1` - March 14th, 2024, version 1
|
|
|
|
You can see there are two parts to the version identifier:
|
|
|
|
- The date (in reverse format)
|
|
- The version number
|
|
|
|
Versions numbers are incremented each time a new version is created for that date and environment. So it's possible to have `20240313.1` in both the `dev` and `prod` environments.
|
|
|
|
## Version locking
|
|
|
|
When a task run starts it is locked to the latest version of the code (for that environment). Once locked it won't change versions, even if you deploy new versions. This is to ensure that a task run is not affected by changes to the code.
|
|
|
|
### Child tasks and version locking
|
|
|
|
Trigger and wait functions version lock child task runs to the parent task run version. This ensures the results from child runs match what the parent task is expecting. If you don't wait then version locking doesn't apply.
|
|
|
|
| Trigger function | Parent task version | Child task version | isLocked |
|
|
| ----------------------- | ------------------- | ------------------ | -------- |
|
|
| `trigger()` | `20240313.2` | Latest | No |
|
|
| `batchTrigger()` | `20240313.2` | Latest | No |
|
|
| `triggerAndWait()` | `20240313.2` | `20240313.2` | Yes |
|
|
| `batchTriggerAndWait()` | `20240313.2` | `20240313.2` | Yes |
|
|
|
|
## Local development
|
|
|
|
When running the local server (using `npx trigger.dev dev`), every relevant code change automatically creates a new version of all tasks.
|
|
|
|
So a task run will continue running on the version it was locked to. We do this by spawning a new process for each task run. This ensures that the task run is not affected by changes to the code.
|
|
|
|
## Deployment
|
|
|
|
Every deployment creates a new version of all tasks for that environment.
|
|
|
|
## Retries and reattempts
|
|
|
|
When a task has an uncaught error it will [retry](/v3/errors-retrying), assuming you have not set `maxAttempts` to 0. Retries are locked to the original version of the run.
|
|
|
|
If all the attempts have failed you can start a [reattempt](/v3/reattempting-replaying). This will be version locked to the original version of the run.
|
|
|
|
## Replays
|
|
|
|
A "replay" is a new run of a task that uses the same inputs but will use the latest version of the code. This is useful when you fix a bug and want to re-run a task with the same inputs. See [replays](/v3/reattempting-replaying) for more information.
|