Files
Axel Niklasson Yun b89cd41f61 Reorganize examples into folders with READMEs (#42)
* Reorganize examples into folders with READMEs

Move each CI example into its own directory with a platform-conventional
filename and a README explaining when to use it, how it works, and setup
steps. Update SKILL.md links to point to the new folder paths.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* Fix inaccurate customization guidance in READMEs

- GitLab CI continuous: clarify that $CI_DEFAULT_BRANCH is a predefined
  variable and show how to replace it in the rule expression
- GitHub Actions scheduled: note that branch pattern changes must also
  update startsWith() guards and version derivation in the workflow

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* Rework docs

* Rename example files to platform conventions

Use the filename each CI platform expects: `linear-release.yml` for
GitHub Actions workflows, `config.yml` for CircleCI, `.gitlab-ci.yml`
for GitLab CI.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-13 12:41:10 +02:00
..

GitHub Actions — Scheduled Pipeline

Releases follow a branch cut model where changes collect over time and move through stages before shipping.

When to use

Use this when your team cuts release branches for stabilization. Main collects changes into the current release, a release/* branch is cut for stabilization, and branch creation auto-promotes to "code freeze".

How it works

  • Push to main: Syncs issues to the current started release (no explicit version).
  • Push to release/*: Derives the version from the branch name and syncs with that version. On branch creation, auto-promotes the release to "code freeze".
  • Manual dispatch: Runs update or complete with the specified stage and version, for later stage transitions and final completion.

Setup

  1. Create a release pipeline in Linear (Settings → Releases) and grab the access key.
  2. Add LINEAR_ACCESS_KEY as a repository secret (Settings → Secrets and variables → Actions → New repository secret).
  3. Copy linear-release.yml into .github/workflows/.

Customization

  • Branch patterns: Change release/** in the push trigger and update every startsWith(github.ref_name, 'release/') guard and the ${GITHUB_REF_NAME#release/} version derivation in the workflow to match your release branch convention.
  • Stage names: Replace code freeze with whatever your first stage is called.
  • Version derivation: The example strips release/ from the branch name. Adjust if your branch naming differs.

Monorepo note

GitHub Actions paths applies to all branches in a push trigger. To path-filter main without filtering release branches, split into two workflow files:

  1. File 1 (main): Add paths: [...] to the push trigger, keep only the main sync step.
  2. File 2 (release): Keep the release branch + workflow_dispatch logic as-is.

Add include_paths to the action in both files.