ci: TRAC-881 Split Linear pipelines per branch and name releases#3091
ci: TRAC-881 Split Linear pipelines per branch and name releases#3091chanceaclark wants to merge 1 commit into
Conversation
canary and integrations/makeswift shared one Linear pipeline with no version pinned on sync, so with no release currently open, whichever branch pushed first would create one and the other branch's sync would attach to that same release instead of starting its own. Two independently-versioned products need two independent release trains, so each branch now targets its own pipeline via its own access key (LINEAR_ACCESS_KEY for canary, LINEAR_MAKESWIFT_ACCESS_KEY for integrations/makeswift). Also give the in-progress release a descriptive name instead of Linear's default "New release", and rename it to the real package@version tag once `complete` fires. Refs TRAC-881 Co-Authored-By: Claude <noreply@anthropic.com>
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Bundle Size ReportComparing against baseline from No bundle size changes detected. |
Unlighthouse Performance Comparison — VercelComparing PR preview deployment Unlighthouse scores vs production Unlighthouse scores. Summary ScoreAggregate score across all categories as reported by Unlighthouse.
Category Scores
Core Web Vitals
|
1 participant
Jira: TRAC-881
What/Why?
Fast-follow to #3085/#3086/#3090.
canaryandintegrations/makeswiftwere sharing one Linear pipeline ("Catalyst Release") with noversionpinned onsync—synctargets "whatever release is currently open," so with no release in progress, whichever branch pushed first would create one and the other branch'ssyncwould attach its issues to that same release instead of starting its own. Two independently-versioned products (each with their own npm package, semver cadence, and release cut timing) need two independent release trains, not one shared "current release."Splits the
access_keyper branch (LINEAR_ACCESS_KEYfor canary, a newLINEAR_MAKESWIFT_ACCESS_KEYfor integrations/makeswift) so each targets its own Linear pipeline entirely — no shared state, no collision risk.integrations/makeswift's pipeline/key still needs to be created in Linear before this is meaningful on that branch (tracked separately).Also sets a descriptive
nameon the in-progress release instead of Linear's default "New release" (e.g.@bigcommerce/catalyst-core (unreleased)), and renames it to the realpackage@versiontag oncecompletefires.Testing
Requires the
LINEAR_MAKESWIFT_ACCESS_KEYsecret to exist before merging, otherwise theintegrations/makeswiftsync/complete steps will fail on missing access key. Watch the next push to canary to confirm the release shows the descriptive name pre-publish and gets renamed to the version tag on completion.