Skip to content

Parse MR number properly for Gitlab#72

Merged
RomainCscn merged 1 commit into
mainfrom
romain/lin-70195-parse-mr-numbers-from-linear-release
May 13, 2026
Merged

Parse MR number properly for Gitlab#72
RomainCscn merged 1 commit into
mainfrom
romain/lin-70195-parse-mr-numbers-from-linear-release

Conversation

@RomainCscn

@RomainCscn RomainCscn commented May 13, 2026

Copy link
Copy Markdown
Collaborator

Properly detect the MR number from GitLab when the merge method permits it.

@linear-code

linear-code Bot commented May 13, 2026

Copy link
Copy Markdown
@RomainCscn RomainCscn requested a review from axelniklasson May 13, 2026 08:25
@RomainCscn RomainCscn merged commit 3b0ebdb into main May 13, 2026
10 checks passed
@RomainCscn RomainCscn deleted the romain/lin-70195-parse-mr-numbers-from-linear-release branch May 13, 2026 09:44
RomainCscn added a commit that referenced this pull request May 19, 2026
GitLab supports subgroup nesting up to 20 levels, so a remote URL like
`git@gitlab.com:my-org/my-group/my-repo.git` is valid but the existing
`[^/]+/([^/]+?)` regex rejected it and `parseRepoUrl` returned null.
With GitLab MR detection from #72 in play, `sync` then threw
"Repository info is required to sync a release with pull request
references" (src/index.ts:407).

The split mirrors `parseProjectPathName` in linear-app's
common/src/models/IntegrationHelper.ts — owner is the first segment,
name is everything else. That matches how Linear's GitLab webhook
stores `attachment.metadata.repoLogin/repoName`, which is what the
CLI's `repositoryOwner`/`repositoryName` join against during release
sync. The convention is symmetric for single-segment URLs (GitHub,
Bitbucket, simple GitLab), so behavior is unchanged for those.

Adds a regression suite that locks the cross-repo contract by running
`parseRepoUrl` against the literal linear-app split logic.

Fixes #83
RomainCscn added a commit that referenced this pull request May 19, 2026
GitLab supports subgroup nesting up to 20 levels, so a remote URL like
`git@gitlab.com:my-org/my-group/my-repo.git` is valid but the existing
`[^/]+/([^/]+?)` regex rejected it and `parseRepoUrl` returned null.
With GitLab MR detection from #72 in play, `sync` then threw
"Repository info is required to sync a release with pull request
references" (src/index.ts:407).

The split mirrors `parseProjectPathName` in linear-app's
common/src/models/IntegrationHelper.ts — owner is the first segment,
name is everything else. That matches how Linear's GitLab webhook
stores `attachment.metadata.repoLogin/repoName`, which is what the
CLI's `repositoryOwner`/`repositoryName` join against during release
sync. The convention is symmetric for single-segment URLs (GitHub,
Bitbucket, simple GitLab), so behavior is unchanged for those.

Adds a regression suite that locks the cross-repo contract by running
`parseRepoUrl` against the literal linear-app split logic.

Fixes #83
RomainCscn added a commit that referenced this pull request May 19, 2026
GitLab supports subgroup nesting up to 20 levels, so a remote URL like
`git@gitlab.com:my-org/my-group/my-repo.git` is valid but the existing
`[^/]+/([^/]+?)` regex rejected it. `parseRepoUrl` returned null and,
once GitLab MR-trailer detection (#72) fires for a sync, syncRelease
threw "Repository info is required to sync a release with pull
request references" (src/index.ts:407).

The split keeps the first path segment as owner and folds the rest
into name (e.g. owner=group, name=subgroup/repo). This matches the
identifier Linear's API uses for GitLab merge requests during release
sync, so the (owner, name) pair we send up joins correctly against
stored MR metadata.

Single-segment URLs (GitHub, Bitbucket, simple GitLab) are symmetric
under this split, so behavior is unchanged for them - all existing
tests pass without modification.

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

Labels

None yet

2 participants