DEV Community

rndmh3ro
rndmh3ro

Posted on • Originally published at zufallsheld.de on

Working with Gitlab on the CLI

#gitlab #cli #glab

Glab is an open-source tool that allows you to work with GitLab from the command line, eliminating the need to switch to a browser to create or approve merge requests, start a pipeline run, or view issues.

Glab can work with repositories hosted on gitlab.com as well as with your own GitLab instances. The tool automatically detects which instance it should work with.

The CLI tool was started by Clement Sam and has been an official GitLab product since 2022.

Setup

Glab can be installed in various ways. Since it is written in Golang, the executable can be easily downloaded and run from the releases page. Alternatively, Glab is also available in various package repositories. It runs on Linux, Windows, and macOS.

All installation options can be found here!

Registering with the GitLab Instance

Before working with repositories, you need to authenticate with the GitLab instance. For this, you need a Personal Access Token, which you can create in your GitLab profile. For the gitlab.com instance, you can create it here. Assign a name to the token and select the “api” and “write_repository” permissions. The generated token will be needed in the next step.

Now, log in to the GitLab instance using the token by running glab auth login and answering the prompts.

> glab auth login
? What GitLab instance do you want to log into? gitlab.com
- Logging into gitlab.com
? How would you like to login? Token

Tip: you can generate a Personal Access Token here https://gitlab.com/-/profile/personal_access_tokens
The minimum required scopes are 'api' and 'write_repository'.
? Paste your authentication token: **************************? Choose default git protocol HTTPS
? Authenticate Git with your GitLab credentials? Yes
- glab config set -h gitlab.com git_protocol https
✓ Configured git protocol
- glab config set -h gitlab.com api_protocol https
✓ Configured API protocol
✓ Logged in as rndmh3ro
Enter fullscreen mode Exit fullscreen mode

You can verify a successful login with glab auth status.

> glab auth status
gitlab.com
  ✓ Logged in to gitlab.com as rndmh3ro (/home/segu/.config/glab-cli/config.yml)
  ✓ Git operations for gitlab.com configured to use https protocol.
  ✓ API calls for gitlab.com are made over https protocol
  ✓ REST API Endpoint: https://gitlab.com/api/v4/
  ✓ GraphQL Endpoint: https://gitlab.com/api/graphql/
  ✓ Token: **************************
git.example.com
  ✓ Logged in to git.example.com as segu (/home/segu/.config/glab-cli/config.yml)
  ✓ Git operations for git.example.com configured to use https protocol.
  ✓ API calls for git.example.com are made over https protocol
  ✓ REST API Endpoint: https://git.example.com/api/v4/
  ✓ GraphQL Endpoint: https://git.example.com/api/graphql/
  ✓ Token: **************************
Enter fullscreen mode Exit fullscreen mode

Working with Repositories

Once successfully logged into the GitLab instance, you can work with repositories using glab.

Cloning a Repository

To clone repositories with glab, run glab repo clone path/to/repo, followed by an optional target directory.

> glab repo clone gitlab-org/cli
Cloning into 'cli'...
remote: Enumerating objects: 18691, done.
remote: Counting objects: 100% (72/72), done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 18691 (delta 53), reused 39 (delta 37), pack-reused 18619
Receiving objects: 100% (18691/18691), 22.98 MiB | 5.97 MiB/s, done.
Resolving deltas: 100% (12391/12391), done.
Enter fullscreen mode Exit fullscreen mode

If you have multiple repositories in a group to clone, you can do this using glab as well. Use the --group option (or -g) to clone all repositories in the group sequentially:

> GITLAB_HOST=gitlab.com glab repo clone -g gitlab-org
fatal: destination path 'verify-mr-123640-security-policy-project' already exists and is not an empty directory.
Cloning into 'verify-mr-123640'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
Cloning into 'without-srp'...
remote: Enumerating objects: 30, done.
remote: Counting objects: 100% (14/14), done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 30 (delta 7), reused 4 (delta 4), pack-reused 16
Receiving objects: 100% (30/30), 5.94 KiB | 5.94 MiB/s, done.
Resolving deltas: 100% (9/9), done.
Cloning into 'container-scanning-with-sbom'...
Enter fullscreen mode Exit fullscreen mode

Working with Merge Requests

After checking out the repository, you can start working on issues or merge requests (MRs).

A typical code change process often looks like this: You make your code changes, commit them, and push them to GitLab. Then, you want to create a merge request. Normally, you would now switch to the GitLab website to create the MR. Thanks to glab, you don’t need to leave the command line.

Using glab mr create, you can interactively create an MR. You will be guided through the creation process, where you specify the title and description, and then you will be asked if you want to create the MR directly or view it in the web frontend before creating it.

> glab mr create
? Choose a template Open a blank merge request
? Title: New Feature
? Description <Received>
? What's next? Submit

Creating merge request for test into master in gitlab-org/cli

!351 New Feature (test)
https://gitlab.com/gitlab-org/cli/-/merge_requests/1297
Enter fullscreen mode Exit fullscreen mode

You can then view it. If you want to do this in the browser, run glab mr view with the --web (or -w) parameter.

> glab mr view -w 1297
Enter fullscreen mode Exit fullscreen mode

You can also view the same content directly on the command line (including comments):

> glab mr view 1297 -R gitlab-org/cli
open • opened by rndmh3ro about 1 hour ago
docs: add installation options with wakemeops !1297

  ## Description

  Add installation options with wakemeops-repository.

  Note: I'm not affiliated with WakeMeOps, just a happy user.

  ## Related Issues

  Resolves #1363

  ## How has this been tested?

  not at all.

  ## Screenshots (if appropriate):

  ### Types of changes

  [] Bug fix (non-breaking change which fixes an issue)
  [] New feature (non-breaking change which adds functionality)
  [] Breaking change (fix or feature that would cause existing functionality
  to change)
  [✓] Documentation
  [] Chore (Related to CI or Packaging to platforms)
  [] Test gap

0 upvotes • 0 downvotes • 5 comments
Labels: Community contribution, documentation, linked-issue, tw::triaged, workflow::ready for review
Assignees: rndmh3ro
Reviewers: aqualls
Pipeline Status: success (View pipeline with `glab ci view add_wakemeops_docs`)
Approvals Status:
Rule "All Members" insufficient approvals (0/1 required):

Rule "/docs/" sufficient approvals (0/0 required):
Amy Qualls aqualls -

✓ This merge request has 1 changes

View this merge request on GitLab: https://gitlab.com/gitlab-org/cli/-/merge_requests/1297
Enter fullscreen mode Exit fullscreen mode

If you’re not working on the codebase yourself but are reviewing MRs from others, you can list open merge requests with glab mr list.

> glab mr list
Showing 22 open merge requests on gitlab-org/cli (Page 1)

!1297 gitlab-org/cli!1297 docs: add installation options with wakemeops (main) ← (add_wakemeops_docs)
!1296 gitlab-org/cli!1296 fix(repo view): consider current host when viewing different repositories (#1362) (main) ← (1362_repo_view)
!1295 gitlab-org/cli!1295 fix: `glab mr delete` should work properly for forks (main) ← (fix_mr_delete)
Enter fullscreen mode Exit fullscreen mode

Afterwards, you can check out the MR you want to review:

> glab mr checkout 1297
Enter fullscreen mode Exit fullscreen mode

If you’re satisfied with the content, you can add a note to the Merge Request and then approve it directly:

> glab mr note -R gitlab-org/cli -m "LGTM"

> glab mr approve
- Approving Merge Request !1297
✓ Approved
Enter fullscreen mode Exit fullscreen mode

And of course, you can also merge the MR right away:

> glab mr merge
? What merge method would you like to use? Rebase and merge
? What's next? Submit
✓ Rebase successful
! No pipeline running on test
✓ Rebased and merged
!1297 New Feature (test)
https://gitlab.com/gitlab-org/cli/-/merge_requests/1297
Enter fullscreen mode Exit fullscreen mode

At the end of the day, you can view your merged MRs by using glab mr list options to see only merged (-M) or your own (-a @me) MRs:

> glab mr list -M -a @me
Showing 4 merged merge requests on gitlab-org/cli (Page 1)

!1279 gitlab-org/cli!1279 feat(schedule): Add commands to create and delete schedules (main) ← (create_del_sched)
!1176 gitlab-org/cli!1176 feat(schedule): Add command to run schedules (main) ← (run_schedule)
!1143 gitlab-org/cli!1143 docs: remove duplicate defaults in help (main) ← (fix_help_doc)
!1112 gitlab-org/cli!1112 feat(schedule): Add command to list schedules (main) ← (sched_list)
Enter fullscreen mode Exit fullscreen mode

Working with Pipelines

Code changes are tested through an automatic CICD pipeline. Naturally, glab offers the ability to work with pipelines.

To start a pipeline on the main branch, use the following command:

> glab ci run -b main
Created pipeline (id: 540823), status: created, ref: main, weburl: https://git.example.com/example/project/-/pipelines/540823
Enter fullscreen mode Exit fullscreen mode

You can view the status of the pipeline like this:

> glab ci status
(failed) • 01m 11s lint test

https://git.example.com/example/project/-/pipelines/540812
SHA: 275cb8295c69db166e1b1c94936d4c4b67463701
Pipeline State: failed

? Choose an action: Exit
Enter fullscreen mode Exit fullscreen mode

If a pipeline has failed, you can view the logs using glab ci trace:

> glab ci trace

Searching for latest pipeline on test...
Getting jobs for pipeline 540812...

? Select pipeline job to trace: kics-scan (1209237) - failed

Getting job trace...
Showing logs for kics-scan job #1209237
Running with gitlab-runner 14.10.1 (f761588f)
  on example-shared-docker swAou6b9
Resolving secrets
Preparing the "docker" executor
Enter fullscreen mode Exit fullscreen mode

glab works excellently with Unix pipes, so you can easily grep for errors:

> glab ci trace 1209237 | grep -i failed
Queries failed to execute: 10
ERROR: Job failed: exit code 50
Enter fullscreen mode Exit fullscreen mode

Linting

Speaking of errors - you can incorporate them wonderfully into the CICD configuration file, the .gitlab-ci.yml.

If you change this file, for example to add a new stage, and make a mistake, you will usually only notice it after you have pushed your changes and wonder why the pipeline does not start.

Fortunately, you can check (“lint”) the configuration with glab.

If an error has crept in, glab ci lint will detect it.

> glab ci lint
Validating...
.gitlab-ci.yml is invalid
1 (<unknown>): did not find expected key while parsing a block mapping at line 2 column 1
Enter fullscreen mode Exit fullscreen mode

After correction, the linting will then report success:

> glab ci lint
Validating...
✓ CI/CD YAML is valid!
Enter fullscreen mode Exit fullscreen mode

Working with Schedules

I am particularly proud of the feature to create and run Pipeline Schedules with glab, because I implemented it.

Pipeline Schedules are designed to automatically run pipelines at regular intervals.

You can create these with glab. To do this, you pass a cron expression (which defines when the pipeline should run), a description, and the branch on which the pipeline should run:

> glab schedule create --cron "0 2 * * *" --description "Run main pipeline everyday" --ref "main" --variable "foo:bar"
Created schedule
Enter fullscreen mode Exit fullscreen mode

You can view the created pipeline schedule with glab schedule list:

> glab schedule list
Showing 1 schedules on example/project (Page 1)

ID Description Cron Owner Active
1038 Run main pipeline everyday * * * * * segu true
Enter fullscreen mode Exit fullscreen mode

To run the pipeline schedule outside the defined rhythm, start it with glab schedule run:

> glab schedule run 1038
Started schedule with ID 1038
Enter fullscreen mode Exit fullscreen mode

And if it is no longer needed, you can simply delete it:

> glab schedule delete 1038
Deleted schedule with ID 1038
Enter fullscreen mode Exit fullscreen mode

glab API

Not all functions that Gitlab offers are yet usable with glab. For such cases, it is possible to communicate directly with the Gitlab API using glab api.

The command to display the pipeline schedules (glab schedule list) mentioned in the previous section can be replicated using a glab api call:

> glab api projects/:fullpath/pipeline_schedules/
[
  {
    "id": 1038,
    "description": "Run main pipeline everyday",
    "ref": "main",
    "cron": "* * * * *",
    "cron_timezone": "UTC",
    "next_run_at": "2023-06-22T08:33:00.000Z",
    "active": true,
    "created_at": "2023-06-22T08:24:02.199Z",
    "updated_at": "2023-06-22T08:24:02.199Z",
    "owner": {
      "id": 97,
      "username": "segu",
      "name": "Sebastian Gumprich",
      "state": "active",
    }
  }
]
Enter fullscreen mode Exit fullscreen mode

You can also delete the pipeline schedule this way:

> glab api projects/:fullpath/pipeline_schedules/1038 -X DELETE

> glab api projects/:fullpath/pipeline_schedules/1038
glab: 404 Pipeline Schedule Not Found (HTTP 404)
{
  "message": "404 Pipeline Schedule Not Found"
}
Enter fullscreen mode Exit fullscreen mode

Aliases

To avoid having to remember the sometimes more complicated API calls, glab has functionality to create aliases.

Two aliases are already set up by default, which you can display as follows:

> glab alias list
ci pipeline ci
co mr checkout
Enter fullscreen mode Exit fullscreen mode

So if you want to check out a merge request, you can simply call glab co instead of glab mr checkout.

You can define your own aliases as follows:

> glab alias set schedule_list 'api projects/:fullpath/pipeline_schedules/'
- Adding alias for schedule_list: api projects/:fullpath/pipeline_schedules/
✓ Added alias.
Enter fullscreen mode Exit fullscreen mode

And of course, you can delete them again:

> glab alias delete schedule_list
✓ Deleted alias schedule_list; was api projects/:fullpath/pipeline_schedules/
Enter fullscreen mode Exit fullscreen mode

Set Variables from GitlabCI Locally

Another useful glab feature is working with CICD variables.

You can display, create, and delete these as well:

> glab variable list

> glab variable set foo bar
✓ Created variable foo for 7001-07/nrwsp with scope *

> glab variable get foo
bar

> glab variable delete foo
✓ Deleted variable foo with scope * for 7001-07/nrwsp
Enter fullscreen mode Exit fullscreen mode

The variables created this way can be used locally in a simple manner.

If you use Terraform, for example, you can set your TF_VAR variables easily by setting the output of glab variable get as an environment variable.

export TF_VAR_db_root_password=$(glab variable get TF_VAR_db_root_password)
export TF_VAR_secret_key=$(glab variable get TF_VAR_secret_key)
export TF_VAR_access_key=$(glab variable get TF_VAR_access_key)
Enter fullscreen mode Exit fullscreen mode

If you copy these exports into your README, each team member can set the correct Terraform variables with a simple copy-paste, without having to copy them from a password manager in a cumbersome way.

Bash-Completion and Further Information

If you want to know what else glab can do - the bash autocompletion shows it to you:

glabs autocomplete shows explanations along with completions!

And many more details can of course be found on the Homepage of glab.

Top comments (0)

Read next

aamfahim profile image

Fast-Forward merge VS Three-Way Recursive merge

Abdullah Al Mamun Fahim -

mlamina profile image

How I ended up building my own AI Dev Assistant from scratch

Marco Lamina -

pradumnasaraf profile image

How to Publish a Golang Package

Pradumna Saraf -

jpmcb profile image

Introducing the Pizza CLI

John McBride -