You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Provision and migrate built-in and custom GitLab role credentials #7498
GitLab installations can currently provision the shared bot credential, but they cannot provision and distribute independent Poller, Analyst, Coder, or administrator-registered custom-role credentials while preserving a working installation during migration.
What should happen
Add an additive provisioning and migration path that:
Creates or enrolls credentials for the three built-in roles and registered custom roles.
Supports a custom role reusing an existing role credential where appropriate, or using its own administrator-provided credential.
Stores and distributes role credentials through protected, masked CI configuration.
Detects partial provisioning and reports which roles are ready.
Leaves the existing shared credential available for explicitly enabled migration or rollback.
Supports reinstall, convergence, drift detection, and uninstall without deleting credentials that are still in use.
Preserves already-running jobs during migration.
Do not revoke or remove the shared credential until all required role provisioning and distribution has been validated.
Acceptance criteria
A fresh installation can provision the three built-in roles.
An administrator can add a registered custom role without a code change.
An existing shared-credential installation can migrate incrementally.
A failed or partial distribution leaves the prior working path usable.
Secret values are never exposed in logs, status output, or issue comments.
This issue is clearly scoped and ready to implement once its stated dependency lands. It explicitly depends on #7497, which defines the role-aware GitLab credential contract (stable role names, secret identifiers, migration/rollback feature gates, and drift/status diagnostics) that this provisioning-and-migration work needs to build against. #7497 is currently open with no in-flight pull request, so implementation here would be premature — building the provisioning path before the contract is finalized risks rework if role names, gate semantics, or status reporting change.
Once #7497 merges, this issue's acceptance criteria (fresh install, incremental migration, safe partial-failure rollback, no secret leakage, and test coverage across install/migration/retry/rollback/reinstall/drift/uninstall) are specific enough to hand to a developer without further clarification.
Labels: This is a feature-category sub-issue of the GitLab three-role identity migration (parent #7496) that is blocked on the still-open contract issue #7497, matching the repo convention of pairing blocked with type/feature/feature/component/mint seen on similar credential-provisioning issues (#5633, #5964, #6516).
changed the title [-]Provision and migrate GitLab Poller, Analyst, and Coder credentials[/-][+]Provision and migrate built-in and custom GitLab role credentials[/+]on Sep 20, 2026
This issue remains blocked on its stated dependency. It depends on the role-aware GitLab credential contract being defined first, since provisioning needs stable role names, credential-reference semantics, and migration/rollback gate definitions to build against.
Checked again: the dependency issue is still open with no pull request addressing it (verified via the closing-PR reference query and targeted PR searches). Nothing has changed since the previous triage pass.
Once the dependency merges, this issue acceptance criteria are clear enough to hand to a developer without further clarification.
The previously identified blocker is resolved: #7497 (the role-aware GitLab credential contract) merged via #7506 and is now closed, so this issue is unblocked and ready for implementation.
The merged contract in internal/gitlabroles and docs/contributing/gitlab-role-credentials.md gives concrete primitives to build against -- the role registry, credential-reference model (own vs. reused), and the FULLSEND_GITLAB_ROLE_MIGRATION gate. No open PR currently targets this issue, so this is a fresh implementation, not in-flight work.
The natural extension point is the existing shared-credential provisioning pipeline in internal/repos (install/converge/drift/probe/uninstall), generalized to walk the role registry instead of assuming a single shared token. See the triage summary for a proposed test matrix covering fresh install, custom-role registration, partial migration/retry/rollback, reinstall/drift/uninstall safety, and secret-leakage prevention.
Next steps:
/fs-code — agent creates a PR to implement this issue
/fs-code <your instruction> — agent implements with your specific guidance
Activity
fullsend-ai-triage commentedon Sep 20, 2026
🤖 Finished Triage · ✅ Success · Started 3:11 AM UTC · Completed 3:14 AM UTC
Commit:
8cbd255· View workflow run →Runtime: claude · Model: sonnet → claude-sonnet-5 · Effort: high · Cost: $0.38
fullsend-ai-triage commentedon Sep 20, 2026
This issue is clearly scoped and ready to implement once its stated dependency lands. It explicitly depends on #7497, which defines the role-aware GitLab credential contract (stable role names, secret identifiers, migration/rollback feature gates, and drift/status diagnostics) that this provisioning-and-migration work needs to build against. #7497 is currently open with no in-flight pull request, so implementation here would be premature — building the provisioning path before the contract is finalized risks rework if role names, gate semantics, or status reporting change.
Once #7497 merges, this issue's acceptance criteria (fresh install, incremental migration, safe partial-failure rollback, no secret leakage, and test coverage across install/migration/retry/rollback/reinstall/drift/uninstall) are specific enough to hand to a developer without further clarification.
Blocked by:
Labels: This is a feature-category sub-issue of the GitLab three-role identity migration (parent #7496) that is blocked on the still-open contract issue #7497, matching the repo convention of pairing blocked with type/feature/feature/component/mint seen on similar credential-provisioning issues (#5633, #5964, #6516).
[-]Provision and migrate GitLab Poller, Analyst, and Coder credentials[/-][+]Provision and migrate built-in and custom GitLab role credentials[/+]fullsend-ai-triage commentedon Sep 20, 2026
🤖 Finished Triage · ✅ Success · Started 12:40 PM UTC · Completed 12:45 PM UTC
Commit:
95a4241· View workflow run →Runtime: claude · Model: sonnet → claude-sonnet-5 · Effort: high · Cost: $0.58
fullsend-ai-triage commentedon Sep 20, 2026
This issue remains blocked on its stated dependency. It depends on the role-aware GitLab credential contract being defined first, since provisioning needs stable role names, credential-reference semantics, and migration/rollback gate definitions to build against.
Checked again: the dependency issue is still open with no pull request addressing it (verified via the closing-PR reference query and targeted PR searches). Nothing has changed since the previous triage pass.
Once the dependency merges, this issue acceptance criteria are clear enough to hand to a developer without further clarification.
Blocked by #7497
Blocked by:
1 remaining item
fullsend-ai-triage commentedon Sep 20, 2026
🤖 Finished Triage · ✅ Success · Started 5:00 PM UTC · Completed 5:04 PM UTC
Commit:
d318c83· View workflow run →Runtime: claude · Model: sonnet → claude-sonnet-5 · Effort: high · Cost: $0.40
fullsend-ai-triage commentedon Sep 20, 2026
The previously identified blocker is resolved: #7497 (the role-aware GitLab credential contract) merged via #7506 and is now closed, so this issue is unblocked and ready for implementation.
The merged contract in
internal/gitlabrolesanddocs/contributing/gitlab-role-credentials.mdgives concrete primitives to build against -- the role registry, credential-reference model (own vs. reused), and theFULLSEND_GITLAB_ROLE_MIGRATIONgate. No open PR currently targets this issue, so this is a fresh implementation, not in-flight work.The natural extension point is the existing shared-credential provisioning pipeline in
internal/repos(install/converge/drift/probe/uninstall), generalized to walk the role registry instead of assuming a single shared token. See the triage summary for a proposed test matrix covering fresh install, custom-role registration, partial migration/retry/rollback, reinstall/drift/uninstall safety, and secret-leakage prevention.Next steps:
/fs-code— agent creates a PR to implement this issue/fs-code <your instruction>— agent implements with your specific guidanceggallen commentedon Sep 20, 2026
/fs-code
fullsend-ai-coder commentedon Sep 20, 2026
🤖 Finished Code · ✅ Success · Started 5:12 PM UTC · Completed 6:02 PM UTC
Commit:
d318c83· View workflow run →Runtime: pi · Model: xai/grok-4.6 · Effort: high · Cost: $41.73
fix(#7498): preserve migration gate, fix double-counted role failures
docs(#7498): document recovery for failed GitLab role gate write
refactor(fullsend-ai#7497): define extensible GitLab role-credential …
feat(fullsend-ai#7498): provision GitLab built-in and custom role cre…
Merge pull request fullsend-ai#7508 from fullsend-ai/agent/7498-provi…