You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Linear Release supports two pipeline styles, configured in Linear:
36
+
37
+
**Continuous**: Every deployment creates a completed release. Use `sync` after each deploy — the release is created already completed.
38
+
39
+
**Scheduled**: An ongoing release collects changes over time, then moves through stages (e.g. "code freeze", "qa") before completion. Useful for release trains. Use `sync` to add issues, `update` to move between stages, and `complete` to finalize.
Use the [Linear Release setup skill](./skills/linear-release-setup/SKILL.md) to generate CI configuration tailored to your project. It supports GitHub Actions, GitLab CI, CircleCI, and other platforms, and walks you through continuous vs. scheduled pipelines, monorepo path filtering, and more.
Copy file name to clipboardExpand all lines: skills/linear-release-setup/SKILL.md
+97-55Lines changed: 97 additions & 55 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,10 +29,14 @@ Look for existing CI configuration files:
29
29
Gather the following information (skip questions you can infer from the codebase):
30
30
31
31
1.**CI platform** — if not auto-detected, ask which platform they use
32
-
2.**Pipeline type** — continuous (every merge creates a completed release) or scheduled (releases go through stages like staging → production)
32
+
2.**Pipeline type** — continuous (every deploy creates a completed release) or scheduled (a release train where an ongoing release collects changes, then gets completed later)
33
33
3.**Monorepo?** — if the repo has multiple apps/services, ask which paths to track (e.g. `apps/web/**`)
34
-
4.**Deployment stages** — for scheduled pipelines, ask what stages they use (e.g. staging, production)
35
-
5.**Release naming** — whether they want custom names/versions (e.g. `v1.2.0`) or the default (short commit SHA)
34
+
35
+
For scheduled pipelines, also ask:
36
+
37
+
4.**Branch model** — which branches trigger releases? Just `main`, or `main` + release branches (e.g. `release/*`)? This determines what branch patterns the CI workflow should trigger on.
38
+
5.**Release versioning** — how do they version releases? Calendar-based (e.g. `2026.05`), semver (e.g. `1.2.0`), or default (short commit SHA)? And where does the version come from — a CI variable, a file in the repo, a git tag? This determines how `--release-version` gets passed to each command.
39
+
6.**Release stages** — what stages do releases move through before completion (e.g. "code freeze", "qa")?
36
40
37
41
### Step 3: Generate the CI configuration
38
42
@@ -46,34 +50,55 @@ Tell the user to add the `LINEAR_ACCESS_KEY` secret to their CI environment:
The access key is created in Linear under Settings → Releases → Pipelines.
53
+
The access key is created in Linear from the pipeline's settings page. Each pipeline has its own access key.
50
54
51
55
## Key Concepts
52
56
57
+
### Release Pipelines
58
+
59
+
A **release pipeline** represents a deployment lane — e.g. "iOS", "Android", "Web", "EU Region". Each environment or product you ship independently should be its own pipeline. Pipelines are configured in Linear.
60
+
53
61
### Pipeline Types
54
62
55
-
**Continuous pipelines**: Every merge to the main branch creates a completed release. Use a single `sync` command — releases are created in the completed stage automatically.
63
+
**Continuous pipelines**: Every successful deployment creates a new completed release automatically. Use a single `sync` command — the release is created in the completed stage.
64
+
65
+
Example: every merge to `main` triggers a deploy, and `sync` creates a completed release with all the issues from the new commits.
66
+
67
+
**Scheduled pipelines**: There's an ongoing "current" release that collects changes over time. You later move it through stages and complete it. Useful for release trains (e.g. monthly releases, mobile app releases with a review period).
68
+
69
+
-`sync` — adds issues to the current started release (or creates one)
70
+
-`update --stage=<stage>` — moves the release to a stage (e.g. "code freeze", "qa")
71
+
-`complete` — marks the release as done; Linear can then prepare the next started release
72
+
73
+
A typical scheduled flow follows a release branch cut: `main` collects changes into the next release, a release branch (e.g. `release/2026.05`) is cut for stabilization, and `main` switches to the next version. Always pass `--release-version` in scheduled pipelines so each branch targets the correct release.
74
+
75
+
### Release Stages
76
+
77
+
Stages are optional steps a release moves through in a **scheduled** pipeline. They represent phases of the release process, not deployment environments. Examples:
78
+
79
+
- "in progress" — actively collecting changes
80
+
- "code freeze" — no more changes going in
81
+
- "in review" — release is being tested/reviewed
82
+
- "qa" — final quality assurance pass
56
83
57
-
**Scheduled pipelines**: Releases go through deployment stages (e.g. staging → production). Use multiple commands:
84
+
Different deployment environments (staging, production) should be separate pipelines, not stages.
58
85
59
-
-`sync` — creates a release or adds issues to the current release
60
-
-`update --stage=<stage>` — moves the release to a deployment stage
61
-
-`complete` — marks the release as done
86
+
Stages can be **frozen** in Linear. When a release is in a frozen stage, `sync` without an explicit `--release-version` will skip that release and target the next one instead. This acts as a safety net for code freezes: even if a merge lands while the release is frozen, the issues go into the next release. However, always prefer passing `--release-version` explicitly for predictable behavior — frozen stages are a fallback, not a substitute for explicit version targeting.
Patterns use Git pathspec glob syntax, relative to the repository root.
112
+
Patterns use Git pathspec glob syntax, relative to the repository root. Path filters can also be configured in the pipeline settings in Linear. If both are set, the CLI `--include-paths` flag takes precedence.
88
113
89
114
## GitHub Actions Patterns
90
115
@@ -115,11 +140,15 @@ jobs:
115
140
116
141
#### Scheduled Pipeline
117
142
143
+
Each branch must target the correct release version. A common pattern is to derive it from the branch name for release branches (e.g. `release/2026.05` → `2026.05`) and use a CI variable for `main`.
144
+
118
145
```yaml
119
146
name: Linear Release
120
147
on:
121
148
push:
122
-
branches: [main]
149
+
branches:
150
+
- main
151
+
- "release/**"
123
152
workflow_dispatch:
124
153
inputs:
125
154
action:
@@ -131,12 +160,12 @@ on:
131
160
- update
132
161
- complete
133
162
stage:
134
-
description: "Deployment stage (for update)"
163
+
description: "Release stage (for update, e.g. code freeze)"
135
164
required: false
136
165
type: string
137
166
release_version:
138
-
description: "Release version (optional)"
139
-
required: false
167
+
description: "Release version"
168
+
required: true
140
169
type: string
141
170
142
171
jobs:
@@ -147,11 +176,22 @@ jobs:
147
176
with:
148
177
fetch-depth: 0
149
178
150
-
# On push: sync issues to the current release
179
+
# Derive release version from branch name or CI variable
0 commit comments