Summary
On a self-hosted GitLab instance served from a custom domain, linear-release sync always fails:
Error: Variable "$input" got invalid value null at "input.repository.provider"; Expected non-nullable type "String!" not to be null.
Provider detection is a substring match on the remote hostname, so any self-hosted instance not using a gitlab/github/bitbucket domain resolves to null, and that null is then sent to a non-nullable GraphQL field.
Environment
- linear-release v0.14.3
- GitLab CI (self-hosted GitLab), Docker executor, Node 24 / Ubuntu Noble image
- Remote:
git@git.example.com:group/repo
Reproduction
git clone git@git.example.com:group/repo.git # host contains neither "gitlab" nor "github"
cd repo
LINEAR_ACCESS_KEY=... linear-release sync --verbose
Cause
hostToProvider in src/git.ts returns null for unrecognized hosts:
function hostToProvider(host: string): string | null {
if (host === "gitlab.com" || host.includes("gitlab")) return "gitlab";
if (host === "github.com" || host.endsWith(".ghe.com") || host.includes("github")) return "github";
if (host === "bitbucket.org" || host.includes("bitbucket")) return "bitbucket";
return null;
}RepoInfo.provider is typed string | null (src/types.ts:83), and src/index.ts:644 passes it straight into the mutation input where the server declares it String!. The null is anticipated client-side and rejected server-side, so the failure is unconditional rather than a degraded sync.
Note that the rest of the run works fine: the verbose log shows the GitLab merge-request trailer being parsed and the MR number detected correctly. Only the provider field is missing.
Confirmed
Rewriting the remote so the hostname contains gitlab, changing nothing else, makes the same sync succeed:
script:
- git remote set-url origin "https://gitlab.example.com/group/repo.git"
- linear-release sync --verbose
linear-release v0.14.3
No recent releases found; assuming first sync
Found PR number ... (gitlab merge request trailer)
Synced to release <sha> (version: <sha>): pull requests [#...]
Same CLI version, same commit range, same access key — only the remote hostname differs. Provider detection is the sole cause.
Impact
Release tracking cannot be set up at all on these instances without that hack. There's no flag or env var to override the provider (--include-paths, --base-ref, --release-version, etc. are the only sync options; only LINEAR_ACCESS_KEY is read from the environment).
The workaround is also lossy: repository.url is derived from the same hostname, so Linear stores a URL that doesn't resolve. Provider, owner and name come out correct; only the URL is wrong.
Suggested fix
An explicit override, e.g. --repository-provider (with a LINEAR_RELEASE_PROVIDER env equivalent for CI), falling back to the current hostname detection when unset. On GitLab CI the provider could also be inferred from CI_SERVER_URL / GITLAB_CI being present, which would make self-hosted GitLab work with no configuration at all.
Failing that: when the provider can't be determined, either omit repository from the input entirely (the field is already optional) or surface an actionable error, rather than sending a null into a non-nullable field.
Summary
On a self-hosted GitLab instance served from a custom domain,
linear-release syncalways fails:Provider detection is a substring match on the remote hostname, so any self-hosted instance not using a
gitlab/github/bitbucketdomain resolves tonull, and thatnullis then sent to a non-nullable GraphQL field.Environment
git@git.example.com:group/repoReproduction
Cause
hostToProviderinsrc/git.tsreturnsnullfor unrecognized hosts:RepoInfo.provideris typedstring | null(src/types.ts:83), andsrc/index.ts:644passes it straight into the mutation input where the server declares itString!. The null is anticipated client-side and rejected server-side, so the failure is unconditional rather than a degraded sync.Note that the rest of the run works fine: the verbose log shows the GitLab merge-request trailer being parsed and the MR number detected correctly. Only the provider field is missing.
Confirmed
Rewriting the remote so the hostname contains
gitlab, changing nothing else, makes the same sync succeed:Same CLI version, same commit range, same access key — only the remote hostname differs. Provider detection is the sole cause.
Impact
Release tracking cannot be set up at all on these instances without that hack. There's no flag or env var to override the provider (
--include-paths,--base-ref,--release-version, etc. are the onlysyncoptions; onlyLINEAR_ACCESS_KEYis read from the environment).The workaround is also lossy:
repository.urlis derived from the same hostname, so Linear stores a URL that doesn't resolve. Provider, owner and name come out correct; only the URL is wrong.Suggested fix
An explicit override, e.g.
--repository-provider(with aLINEAR_RELEASE_PROVIDERenv equivalent for CI), falling back to the current hostname detection when unset. On GitLab CI the provider could also be inferred fromCI_SERVER_URL/GITLAB_CIbeing present, which would make self-hosted GitLab work with no configuration at all.Failing that: when the provider can't be determined, either omit
repositoryfrom the input entirely (the field is already optional) or surface an actionable error, rather than sending a null into a non-nullable field.