GitLab package v1.0.0

A GitLab personal access token (or project access token) for gitlab.com, held in the client's own secret manager. The stored material must be the complete PRIVATE-TOKEN header value: the token exactly as issued by GitLab, with no scheme prefix added.

GitLab documents that personal access tokens authenticate by sending the token in the PRIVATE-TOKEN header, that every token has an expiry date (expiring at midnight UTC, with a default maximum lifetime of 365 days and email notices before expiry), that revoking a token or rotating it takes effect immediately and leaves the previous value inactive, and that GitLab documents disablement controls that go beyond blocking new issuance: on GitLab Self-Managed and Dedicated (Premium/Ultimate) the instance-wide 'Disable access tokens' setting rejects API requests authenticated with existing personal, group, project and impersonation tokens, and on GitLab.com disabling personal access tokens for a group's enterprise users both stops new creation and disables those users' existing tokens — these are reversible suspensions of use by an administrator, distinct from revoking or rotating an individual token, which invalidates that one value immediately and permanently.

New or replacement tokens must be issued through GitLab, outside AAES. Request the least-privilege scope: read_api covers every read capability in this pack; the two R3 capabilities additionally need api (or a project access token with an equivalent role limited to one project), and nothing broader. Renewal ownership sits with an external deployment process: the executor injects the stored value verbatim and performs no token lifecycle itself, and it must never substitute a different credential without an approved pack change.

Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

The registered host is gitlab.com (GitLab SaaS). Self-managed GitLab instances use an installer-specific host: substitute it into the endpoints, the resource locators and the egress allowlist together — the allowlist matches exactly, so all three must move as one — and substitution is a pack change that requires re-review before enablement.

PROJECT_ID and MERGE_REQUEST_IID in the endpoint paths are placeholders the deployment substitutes with concrete values at registration time, before enabling (PROJECT_ID accepts the numeric project id or the URL-encoded namespace path; MERGE_REQUEST_IID is the project-scoped merge request iid): the pack is installed with the concrete paths it will actually call, not rebound per request.

This pack registers only endpoints the public GitLab API documentation describes: listing projects, listing a project's merge requests, listing a project's pipelines, listing a repository tree, creating a pipeline, and approving a merge request.

Documented exclusions: job trigger or play, pipeline retry, cancel or delete, pipeline variables and schedules, file or commit writes, merge request create, update, merge and unapprove, and every endpoint outside the registered list; each addition is a pack change and requires its own review.

Approval classification: reads sit at the minimum R0 tier. pipeline.trigger is registered as deploy at the minimum R3 tier because GitLab documents that the caller chooses the ref and may pass variables and inputs, so the request body decides which branch or tag builds and what configuration the pipeline sees, and the provider documents pipelines as a way to build, test and deploy code — deploy is one of the designated actions requiring human approval. merge_request.approve is registered as approve at the minimum R3 tier because the approval is recorded under the caller's identity and typically unblocks a merge, and approve is one of the designated actions requiring human approval.

AAES has not been certified by GitLab; reviewable default, not a vendor guarantee.