-
Notifications
You must be signed in to change notification settings - Fork 0
[Stage 3] Define GitLab parity boundary for provider adapters #92
Copy link
Copy link
Open
Labels
area: architecturearea: gitlabhelp wantedExtra attention is neededExtra attention is neededneed helpContribution wanted; scoped but needs implementation or research helpContribution wanted; scoped but needs implementation or research helpstage: 3status: blockedBlocked by another issue or design decisionBlocked by another issue or design decisionwaiting helpWaiting for contributor research, design input, or maintainer discussionWaiting for contributor research, design input, or maintainer discussion
Description
Metadata
Metadata
Assignees
Labels
area: architecturearea: gitlabhelp wantedExtra attention is neededExtra attention is neededneed helpContribution wanted; scoped but needs implementation or research helpContribution wanted; scoped but needs implementation or research helpstage: 3status: blockedBlocked by another issue or design decisionBlocked by another issue or design decisionwaiting helpWaiting for contributor research, design input, or maintainer discussionWaiting for contributor research, design input, or maintainer discussion
Type
Fields
Give feedbackNo fields configured for issues without a type.
Goal: define what GitLab support must share with GitHub adapters and what can remain provider-specific.
Related plan: #82.
Depends on: #33, #84, and #85.
Acceptance criteria:
- Identify shared adapter concepts across GitHub and GitLab.
- Identify GitLab-specific MR and pipeline metadata differences.
- Keep GitLab support optional and investigation-first.
- Recommend whether implementation should wait for GitHub adapter stabilization.