2.1 KiB
| description | type | stage | group | info |
|---|---|---|---|---|
| Internal users documentation. | concepts, reference, dev | none | Development | See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments-to-development-guidelines |
Internal users
Introduced in GitLab 15.4, bots are indicated with a badge in user listings.
GitLab uses internal users (sometimes referred to as "bots") to perform actions or functions that cannot be attributed to a regular user.
These users are created programmatically throughout the codebase itself when necessary, and do not count towards a license limit.
They are used when a traditional user account would not be applicable, for example when generating alerts or automatic review feedback.
Technically, an internal user is a type of user, but they have reduced access and a very specific purpose. They cannot be used for regular user actions, such as authentication or API requests.
They have email addresses and names which can be attributed to any actions they perform.
For example, when we migrated GitLab Snippets to Versioned Snippets in GitLab 13.0, we used an internal user to attribute the authorship of snippets to itself when a snippet's author wasn't available for creating repository commits, such as when the user has been disabled, so the Migration Bot was used instead.
For this bot:
- The name was set to
GitLab Migration Bot. - The email was set to
noreply+gitlab-migration-bot@{instance host}.
Other examples of internal users:
- Alert Bot
- Ghost User
- Support Bot
- Visual Review Bot
- Resource access tokens (including project access tokens).
These are implemented as
project_botusers with aPersonalAccessToken.