Skip to content

feat(tasks): import issues from GitLab - #1552

Open
leoisadev1 wants to merge 1 commit into
worknenjoy:masterfrom
leoisadev1:feat/gitlab-issue-import
Open

leoisadev1 wants to merge 1 commit into
worknenjoy:masterfrom
leoisadev1:feat/gitlab-issue-import

Conversation

@leoisadev1

Copy link
Copy Markdown

Summary

Gitpay can import GitHub and Bitbucket issues. This adds GitLab.com so a URL like https://gitlab.com/mission-center-devs/mission-center/-/issues/3 (the example on #1097) creates a task.

What changed

  • Parse gitlab.com / www.gitlab.com issue URLs, including nested groups, /-/issues/:id, and /-/work_items/:id
  • GitlabConnect client for the public REST API (/projects/:path/issues/:iid, project metadata, languages)
  • Map GitLab opened to gitpay open and description to the issue body the UI already expects
  • GitLab button on both import dialogs; pasting a gitlab.com URL selects GitLab

Tests

Mocha coverage of the parser plus a nock of the shipped GitlabConnect client (12 passing).

Closes #1097

@leoisadev1 leoisadev1 mentioned this pull request Sep 7, 2026
Parse gitlab.com issue and work item URLs, including nested groups,
fetch them through the public GitLab API, and add a GitLab option to
both import dialogs.

Fixes worknenjoy#1097
@alexanmtz

Copy link
Copy Markdown
Member

Thanks for this — the GitLab connector and the import-side work here is a good start, and the title/status sync-on-fetch is genuinely well done.

It's not mergeable as-is yet, though. Two things need to land first:

  1. Claiming is hardcoded to GitHub only — taskClaim.ts rejects any task where task.provider !== 'github'. As it stands, a GitLab bounty could be imported and funded but never claimed or paid out.
  2. There's no GitLab identity/connector yet to verify "the person claiming this bounty is the same person the issue belongs to on GitLab" — that requires either a dedicated OAuth strategy or a schema change, and depends on what GitLab's auth model actually supports (it does have standard OAuth2 apps, so this looks feasible).

On top of that, taskBuilds.ts/taskFetch.ts are growing a large duplicated switch case per provider with no shared interface — we'd like to settle a shared provider-registry shape before adding more cases in that pattern.

We've opened #1563 to work through all of this, and are asking in #1097 for provider-specific verification on the identity/OAuth side. Could you hold off on further work here until that's settled, so effort isn't spent on a shape that ends up changing? We'll follow up on this PR once the architecture discussion lands.

This branch has not been deployed

No deployments
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.

Support for GitLab

2 participants