Repository navigation
Conversation
- Changed plugin ID from com.gorlix.gitlab to com.paca.gitlab. - Updated version to 0.6.0 and minimum core version to v0.20.0 in plugin.json. - Removed unnecessary backend, frontend, MCP, and skills configurations. - Deleted obsolete files: tsconfig.json, vite.config.ts, and SKILL.md. - Updated install script to reflect new plugin ID and version. - Adjusted Docker volume checks and asset staging for the new plugin structure.
feat: update git workflow
Classify each access token at setup (project, group, service account or personal) and store the type, the project or group id and its path on the identity, with a new migration for the columns. Project and group tokens are told by the bot user name GitLab gives them; any other bot user is a service account, whose name its creator may choose, and a human user holds a personal token. Identities stored before get classified lazily on first load. ResolveRepository skips connections whose token cannot cover the repository, requires at least the Developer role so a public project is never bound to a non-member token, and explains what each connection covers (or that its role is too low) when none qualifies. The hint no longer names only group access tokens, which GitLab.com offers on Premium and above. MintCredential refuses writes to non-members too. The display name now says what a connection covers, e.g. "Project token · acme/ui" or "Service account · <name>".
Extend the fake GitLab with project and group bot users, /groups/:id and per-token roles on /projects/:id, and test classification (including service accounts with a chosen name), display names, candidate filtering and ordering, lazy classification of existing rows, a token whose role on its own repository is too low, the error text for a service account, and the refusal of writes at access level 0. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…anges Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Cover both traffic directions for a self-managed instance: adding the host to allowedOutboundDomains before installing, the core limits (public address, trusted certificate), GitLab's default block on local-network webhooks, and why a hook must not be edited by hand. Also note that project and group access tokens need a paid tier on GitLab.com. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat: recognize GitLab token types and their reach when resolving repositories
test: cover change-request edited events for title and description changes
docs: expand self-managed GitLab setup
Migration 0004 carries over what com.gorlix.gitlab 0.5.x kept in its own schema: each project's access token becomes a project-scoped token connection in core, with its repositories, merge requests, task links and task branches. It mirrors the GitHub provider's migration and is a no-op when the old schema or core's git tables are absent; rerunning it creates nothing new. The old schema is left untouched. A migrated identity is completed on first use: its user is asked of GitLab, a webhook secret is generated, then its reach is classified. A token GitLab rejects asks to connect again, and a token the instance key cannot decrypt names ENCRYPTION_KEY. The old plugin's webhooks are recorded and each is deleted once the repository's new hook is registered, only if it still points at the old plugin; failures are best effort and only retryable ones are tried again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Community releases 0.5.0 and 0.5.1 already used the id com.paca.gitlab, so their tables are in this plugin's schema, and 0002 dropped them before anything could carry them over. 0002 now keeps them; 0004 gathers the rows of both releases (0.5.2's schema wins for a project found in both), carries them over and then drops the tables in this schema, as the GitHub provider does with its previous release's. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Rewrites "Upgrading from 0.5.x" for the migration: what is carried over and what is not, the order of the steps for 0.5.0/0.5.1 (same id) and 0.5.2 (com.gorlix.gitlab), what "Try again" does to the old webhooks, and how to back up the database first and roll back. The decryption error now names the instance's ENCRYPTION_KEY, which core hands every plugin. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
scripts/test-legacy-migration runs this plugin's migrations the way core does (one transaction each, SET LOCAL search_path) on Postgres 16 with core's git tables from a Paca checkout, and checks the upgrade from 0.5.2, the in-place upgrade from 0.5.0/0.5.1, both together, a rerun, a fresh install and a plugin-only database, plus the store's own SQL for completing an identity and finding its legacy hooks. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat: migrate the community GitLab plugin's data (0.5.x)
Implement gp.IdentityDescriber and declare identity_description. Describing an identity loads it, which completes one carried over from the community plugin (asks GitLab once, stores the user and webhook secret); a normal identity is answered from the stored record with no API call. Unknown identities report not_found, tokens GitLab rejects report forbidden. Needs the SDK's identity_description support (see the following commit). Refs Paca-AI/paca#661 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Refs Paca-AI/paca#661 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
v0.4.2 ships the identity_description capability and DescribeIdentity. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
feat(spi): describe identities so core learns a migrated handle
Author
|
Opened this PR by mistake. Closing it now |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.