#labdash and glab

#What glab is good at

If the question is "how do I do X from a script", the answer is glab, and labdash's documentation keeps pointing there.

#What labdash is good at

#How labdash reaches GitLab

labdash calls GitLab's GraphQL and REST endpoints directly over HTTPS. It spawns no subprocess and never runs glab or gh.

It also reads and writes nothing that belongs to glab: not the configuration file, not the keyring entries, not the token. Your glab install behaves the same whether labdash is running or not.

#Moving a token across

labdash keeps its own credential, so logging in is a separate step:

labdash auth login                 # OAuth device flow
labdash auth login --with-token    # a personal access token, read from stdin

A personal access token you already hold works with --with-token, provided it carries the api scope, or read_api for read-only mode. Create one at https://<host>/-/user_settings/personal_access_tokens. Piping it in keeps the value out of your shell history:

echo "$GITLAB_TOKEN" | labdash auth login --with-token

labdash validates the token with GET /user before storing it, so a typo fails at login. It then keeps the credential in the OS keyring under com.gitlab.labdash. See security.

#Instance settings

glab's per-host settings have equivalents in labdash's settings file, under camelCase names: apiHost, subfolder, caCert, clientCert, clientKey, insecureSkipVerify, proxy, customHeaders. A corporate instance you already configured for glab will look familiar. See instances.

GITLAB_TOKEN, GITLAB_ACCESS_TOKEN, OAUTH_TOKEN, GITLAB_HOST, GITLAB_URI and GL_HOST are read under the same names glab uses, so an exported variable needs no renaming.

#Using both

glab mr create --fill --yes    # do a thing
labdash                        # watch what happens to it, and to everything else