We want to integrate GitLab with the tools our developers already use and love. This mission drove us to adopt GitLab Workflow for VS Code two years ago and we’ve been iterating on it ever since (spoiler alert: it is an integral part of our future Web IDE). As we thought about potential next projects, we considered that the common denominator for developers, regardless of their choice of editor, is their terminal.
This led us to our next charter: to bring GitLab to the CLI to continue streamlining workflows for developers between their most used technologies.
Similar to our work with VS Code, we wanted to integrate the GitLab DevSecOps platform into all stages of the code writing process. At GitLab, we’re dedicated to open source and we value building in public. It's this commitment to open source and collaboration that helped us take the first step in this project: looking to our community to see if we could partner with them on an existing open source project to bring the CLI to developers faster.
Improving GitLab’s native CLI experience
I’m happy to share that we’ve adopted the open source project glab, which will form the foundation of GitLab’s native CLI experience. The GitLab CLI brings GitLab to your terminal, next to where you’re already working with Git and your code, without switching between applications and browser tabs.
Efficiency at your fingertips
This integration means developers can now achieve the following tasks without ever leaving the terminal:
- Review issues assigned to you.
- Create branches and merge requests for those issues.
- Check the status of pipelines.
- Approve and merge work.
Too excited? Need a tl;dr RIGHT NOW? We have GitLab CLI installation instructions waiting for you! When setting up authentication, we’ve partnered with 1Password to support their new Shell Plugins making it even easier to authenticate your session and keep your credentials secure.
How did we get here?
More than two years ago, Clement Sam (a GitLab Hero) began work on glab because he wanted a tool that made his workflow easier and saved time by avoiding the need to switch between browser tabs, IDE and terminal. He initially shared the script with some of his colleagues who also found it helpful. Ultimately, Clement made the decision to open source it and since then over 80 other contributors have continued to build on the tool, adding commands to interact with merge requests, issues, pipelines, and more.
We heard about glab from Clement back in 2020, when the project was still early in its life cycle. We were excited about the area, but couldn’t commit at the time to giving it the long-term support it deserved. Fast forward to 2022. We felt it made sense to check in with Clement to see how the project was progressing. After a few conversations, everyone involved felt that GitLab would be a great home for long-term support and community contributors. We adopted the project.
Providing a seamless transition
Over the past several months, we’ve been transitioning the project to GitLab. During the transition we’ve learned a lot about what it takes to migrate an active project to new tooling. Our efforts to adapt GitHub Actions to GitLab CI have given us great insights into that process as users, and something we’ll be looking to share more about in a future post. We also needed to unwind some previous documentation changes by converting them back to Markdown, for compatibility with the rest of GitLab’s internal processes.
Furthermore, we knew we needed to provide users with a secure experience. Prior to adoption and launch, our application security team reviewed the project and provided feedback to ensure glab was safe, secure, and ready for more users.
With everything ready to go, we worked across the ecosystem to update distribution methods to point to the new repository. Our goal was to provide a seamless transition for contributors to continue working, and for users to continue receiving updates.
Strengthened by community
It’s taken a small army of people to make the adoption of glab complete. A special thanks to Gary who stepped up to lead the engineering efforts on our side. He’s been wonderfully supported by Kerri, Tomas, and many others inside of GitLab who have had a passion for this project. Our external community has also come along for the ride. We’ve had over over 35 community contributions, ranging from first-time contributors to seasoned glab contributors. (Including Clement, who remains active in the project!).
GitLab CLI v1.24.1 contains over 40 new features, bug fixes, security fixes and many more improvements since the last release. You can see the full changelog on our releases page. Thank you to everyone who’s contributed to make all of this possible.
Want to get started now?
If you’re on macOS (and have Homebrew installed) the fastest way to get started is by running:
brew install glab
This will install the latest version of the GitLab CLI and immediately make it available for you. Not on macOS? We have installation instructions for Windows and Linux too.
As part of getting things setup, you’ll need to set up the CLI to use a personal access token for authentication. You can do this with the glab auth login command and follow the prompts. Alternatively, you can use 1Password Shell Plugins to authenticate your session. With this feature, you can:
Secure your personal access tokens in encrypted 1Password vaults. Authenticate specific terminal sessions to access those tokens by scanning your fingerprint or using other biometrics.
This approach eliminates the need to type tokens or passwords into the terminal while removing plaintext keys from your disk. Plus, as you work across devices or environments, your key moves with you in 1Password, reducing setup time and simplifying collaboration. Check out the 1Password documentation to get started..
What are we doing next?
Now that we’ve officially released the GitLab CLI, we’re going to spend some time taking a closer look at the issue backlog. We want to learn what the community is looking for in a CLI tool, and where opportunities exist to extend capabilities further into developer workflows. You’ll see the GitLab team more involved in discussing feature proposals and triaging bugs as we continue to ramp up on the project.
What do you want to see?
The GitLab CLI was born out of the community, and we want to continue collaborating with all of you in its future direction. If you have ideas for new features or encounter a bug, open an issue and let us know or – in true GitLab form – everything starts with a merge request.
