[pikann]

Summary

Rewrites the GitLab plugin as a Git provider for Paca's platform-neutral Git integration (gitprovider.v1), following paca-plugin-github. Core now owns repositories, merge-request links, triggers, runs and audit; this plugin only adapts GitLab to the SPI.

• Plugin ID com.gorlix.gitlab → com.paca.gitlab, version 0.6.0, minCoreVersion v0.20.0, capability git-provider.
• Backend-only. Removed the plugin's own routes, automation nodes, custom permission, frontend, MCP bundle and the paca-gitlab-workflow skill (core's neutral Git tools, git:* permissions and agent triggers replace them).
• Added thanks to Gorlix, who created the original plugin, in the README.

What it implements

• Identity: access-token form (project/group token recommended, optional read-only token, user-chosen webhook secret). Tokens and secrets are AES-256-GCM encrypted. Self-managed hosts supported.
• Credentials: static (stored token); read-only token for read access; write refused below Developer.
• Repositories: list/resolve by URL or path, subgroups, addressed by numeric id when known.
• Webhooks: secret-token or Standard Webhooks verification; merge requests, notes (with thread/line), issues, pipelines, pushes; deterministic event ids; mention/assignment/review-request/label addressing.
• Reads/writes: merge requests, diffs, threads, comments, issues, checks and job logs, files, code search, branches, labels, reviewers, assignees, merge, rerun checks, webhook registration, commit status (Paca / <agent>).
• Reviews are emulated (discussion per inline comment, then summary note, then approval).

Breaking changes / upgrade

• New plugin ID means a new plugin with a new schema (plugin_data_com_paca_gitlab). The old plugin's data is left untouched and not read; remove the old plugin and set up an identity again.
• Migration 0002_git_provider.sql drops the legacy project-bound tables; nothing is migrated.
• Flows built on the old automation nodes (gitlab.mr_linked, gitlab.merge_mr, …) need rebuilding on core's Git triggers.
• scripts/install-from-release.sh and release.yml now ship backend, migrations and manifest only.

Known limits

• Core does not call EnsureWebhook yet, so webhooks are added by hand per GitLab project (the setup form shows the URL).
• "Request changes" is posted as a note (no REST equivalent); rebase merge is refused (GitLab sets it per project).
• Pipelines of source external (including Paca's own statuses) are not read as CI failures, to avoid run loops.

Testing

• go vet, go test -race (80% coverage), golangci-lint and the TinyGo WASM build are clean.
• The SDK conformance suite (63 subtests) passes against a fake GitLab, plus unit tests for setup, credentials, webhook parsing, reviews, status, checks and webhook management.
• Migrations and the store's SQL verified on a scratch Postgres; manifest accepted by core's PluginManifest.Validate.
• Not tested against a real GitLab instance, and the install script was only syntax-checked.

🤖 Generated with Claude Code