GitLab

Installs glab (the GitLab CLI) and configures shell aliases and per-shell account selection.

What it does

• Auto-installs and updates glab to the latest GitLab release (release tarball on Linux, Homebrew on macOS)
• Bash tab completion for glab
• Keeps GitLab account selection per-shell (GLAB_CONFIG_DIR) so terminals never collide, see Per-shell isolation
• Shell aliases and functions for merge-request, issue, and pipeline workflows

Aliases

Alias	Command	Description
gitlab	gl-account	Show / switch the GitLab account
mrl	glab mr list	List merge requests
mrc	glab mr create	Create a merge request
mrv	glab mr view	View a merge request
gli	glab issue list	List issues
glci	glab ci status	Show the pipeline status

Functions

Function	Description
gl-authenticate	Select an account and run glab auth login in one step
gl-account	Show the current GitLab account, or switch to a named one — launches glab auth login if that account is signed out

Authentication

The role installs the binary but leaves you signed out, so nothing writes credentials during an apply. Sign in once per account with gl-authenticate, which selects the account's GLAB_CONFIG_DIR and then runs the interactive glab auth login:

gl-authenticate personal                            # gitlab.com (SaaS)
gl-authenticate client gitlab.client.example        # a self-hosted instance

gl-account on its own selects the shell's account, and launches the login for you when that account is signed out (gl-authenticate differs in that it always re-runs the login, even for an account already signed in):

gl-account personal        # select the account; if signed out, runs glab auth login

For non-interactive hosts (CI, headless), export a token instead and glab reads it without a login step:

export GITLAB_TOKEN=glpat-...

Multiple GitLab instances and accounts

glab stores credentials in a single config dir (~/.config/glab-cli), keyed per host under hosts:. That covers several different hosts at once out of the box: sign in to each and glab auto-selects the right one from the current repo's origin remote.

glab auth login                                  # gitlab.com (SaaS)
glab auth login --hostname gitlab.client.example # a self-hosted instance

What a single config dir cannot hold is two accounts on the same host (e.g. a personal and a work gitlab.com identity) — one config keeps one token per host. gl-account solves that by giving each account its own config dir, scoped to the shell, and gl-authenticate selects one and logs in together:

gl-authenticate personal                     # ~/.config/glab/accounts/personal
gl-authenticate client gitlab.client.example # ~/.config/glab/accounts/client, self-hosted

gl-account <name> exports GLAB_CONFIG_DIR=~/.config/glab/accounts/<name>; run it with no argument to show the current account and list the ones you have. To override the host for a one-off command, glab still honours GITLAB_HOST:

GITLAB_HOST=gitlab.client.example glab issue list

Per-shell isolation

Account selection lives in the GLAB_CONFIG_DIR environment variable scoped to the current shell, never in a shared current account key. gl-account exports it rather than mutating one global config, so picking an account in one terminal cannot change which GitLab another terminal acts on.

Because selection is env-var driven, every terminal holds its own GitLab account. You can run several sessions at once, each signed in to a different account or instance, including a coding agent like Claude Code, with no shared glab state for them to fight over. The starship prompt reads the same GLAB_CONFIG_DIR/GITLAB_HOST and shows the account (🦊 <account>), so each shell visibly shows the GitLab it is on. This is the per-shell context isolation concept applied to GitLab.