Skip to content

Comments

Migrate label-based releases to release pipelines#4

Open
bhendery wants to merge 2 commits intolinear:mainfrom
bhendery:brian/lin-58611-consider-how-to-migrate-from-labels
Open

Migrate label-based releases to release pipelines#4
bhendery wants to merge 2 commits intolinear:mainfrom
bhendery:brian/lin-58611-consider-how-to-migrate-from-labels

Conversation

@bhendery
Copy link

These files are intended to address the use-case in LIN-58611 -- an org that has pre-existing "release" label groups, with sub labels for each individual release. This was a popular way to model releases in linear prior to the dedicated feature. The script takes a user's API key and UUIDs for the release pipeline, the label group, and optionally stage.

adding readme for the script to the branch on the forked linear-solutions repo
adds actual script to my branch in the forked repo, intended to help customers who want to migrate from parent "releases" and sublabels 1.0, 1.1, 1.2 to release pipelines with releases 1.0, 1.1, 1.2
@bhendery bhendery marked this pull request as draft February 19, 2026 00:10
@bhendery
Copy link
Author

cc @RomainCscn, @blkinney. I don't have permission in the upstream repo to assign reviewers, but letting you know this is here!

@bhendery bhendery marked this pull request as ready for review February 19, 2026 00:14
PARENT_LABEL_ID = ""
RELEASE_PIPELINE_ID = ""
RELEASE_STAGE_ID = ""
# For continuous pipelines, this is optional; we'll fallback to completed if you do not fill this field.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's say instead that this is supported only for scheduled. We don't allow custom stages for continuous.

RELEASE_PIPELINE_ID = ""
RELEASE_STAGE_ID = ""
# For continuous pipelines, this is optional; we'll fallback to completed if you do not fill this field.
# If your pipeline is scheduled, set this field to the desired value. See README for how to find stage IDs.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also usually, comments are above the variable they are mentioning.

Copy link

@RomainCscn RomainCscn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • README says the script is idempotent, but issueToReleaseCreate fails if the issue is already linked to the release. Re-running after a partial run can error. Catch/ignore already exists for that mutation.
  • We intend people to use this with API key only, right? No pipeline access key support?
  • We currently reuse a release if name OR version matches. That can pick the wrong release when names collide. Since pipeline uniqueness is on version, we should match by version first (and only fall back to name if version is empty)
  • Don't think we use LABEL_GROUP_ID in the code?
  • Maybe some reliability improvements: today one failed issue association currently stops the whole migration. For large backfills, we should collect per-issue errors, continue processing, and print a final failure summary.
    • Related to this, might be useful to print some metrics at the end: labels processed, releases created/reused, issues linked, issues skipped/errors. Makes dry-run and audit much easier.

@blkinney
Copy link
Collaborator

Agree with Romain on the retry/failure safeguards. I'd also call out that we might need rate limiting protections on this as well.


release_stage_id: Optional[str] = (args.stage_id or "").strip() or None

if not api_key.startswith(("lin_api_", "Bearer ")):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may be missing something, but I don't think this would ever evaluate in a way that would apply the logic below?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants