The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Create |
| Maturity | Minimal |
| Content Last Reviewed | 2023-04-10 |
Thanks for visiting this direction page on the GitLab CLI. This page belongs to the Code Review group of the Create stage and is maintained by Kai Armstrong (E-Mail).
This direction is constantly evolving and everyone can contribute:
The command line is one of the most important tools in a software engineer's toolkit and the majority of their process and work revolve around tools available there. They customize their CLI with styles and extend it through applications to ensure maximum efficiency while performing tasks. The CLI is the backbone of scripts and workflows developers depend on to complete their work.
Engineers working on contributions often collaborate with product managers, designers and other engineers to complete their work. Initially this collaboration takes place in issues where engineers can ask clarifying questions, review designs and discuss solutions. When engineers begin to work on these contributions, issues serve as the reference document and requirements to complete their task.
Once those contributions have been worked engineers contribute those via a Merge Request. Merge Requests are a collaborative process that involves getting feedback on the work completed and then responding to that feedback through additional revisions and comments.
Configuration files are also common to software development and the tools of the DevOps life cycle. In GitLab there are files like .gitlab-ci.yml and CODEOWNERS which have specific syntaxes and parameters to properly configure. Making changes to these files often involves having documentation available and then validating content through commits or tools outside the editor.
GitLab supports teams collaborating and building software together, however that collaboration is only available inside the GitLab application.
Developers, on the other hand, spend the majority of their time working locally implementing work outlined in issues, responding to merge request feedback and testing/debugging their applications. These tasks are the core of the developer experience, and GitLab should support developers closer to where they're doing their meaningful work to enable them to be more efficient in the delivery of that work.
Configuration Users who configure projects or GitLab need tools to help them be efficient at this process. The GitLab CLI provides methods to create and then manage project configurations which can be important for instance management. Once your project is up and running you can easily manage and test your GitLab CI/CD configuration to ensure it is setup correctly.
Contribution Engineering personas who work on contributing directly to the code in projects need to action feedback from the review process. The GitLab CLI makes it easy to view the contents of an issue you're working on, check the status of merge requests, get feedback and output from running pipelines, and much more.
Automation Automating tasks is an important part of engineering process. The GitLab CLI supports users in both interactive and non-interactive workflows to script repetitive tasks for information during the development process, automate interactions in GitLab CI or produce reporting for external systems.
Flexibility Flexibility in tooling is valuable to support a variety of different workflows and use cases. The GitLab CLI provides an opinionated set of commands for interacting with issues, merge request, and pipelines. However, we also provide a flexible tool that allows you to alias any API interaction to your own commands for your workflow.
In Progress: GitLab CLI User Research Areas
The most important focus to guide work of the GitLab CLI over the next year is to understand existing use patterns from our users and then look for opportunities to extend these. We'll be conducting user research in this area to learn more.
*In Progress:** Paginated results for API Responses
The GitLab CLI is inconsistent in which commands return paginated results and which commands allow you to scroll through pages. Building in reusable pagination so that more commands can take advantage of paged results will make it easier for future contributions and extend the use of existing commands with large returns of data.
Later: OAuth for GitLab CLI
The GitLab CLI currently requires users to generate a personal access token to authenticate commands. Configuring personal access tokens can be challenging and may require frequent rotation which can make using glab more burdensome. In some cases, instances may have personal access tokens disabled which makes it impossible to use.
Later: OAuth for GitLab CLI
The GitLab CLI currently requires users to generate a personal access token to authenticate commands. Configuring personal access tokens can be challenging and may require frequent rotation which can make using glab more burdensome. In some cases, instances may have personal access tokens disabled which makes it impossible to use.
We've recently completed work on tightening up release distribution and focusing our efforts on Homebrew.
We now support homebrew with automated releases and encourage it's use across MacOS, Linux and Windows.
We're currently only focused on the GitLab CLI and continuing to expand the experience for those users.
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
This category is currently at the Viable maturity level, and our next maturity target is Complete (see our definitions of maturity levels). We're continuing to evaluate required components to move to that level.
The software development process involves many people working across various parts of configuration, contribution and review. All of these users work together to advance software projects in their organization.
Engineering personas who are contributing to development, configuring or interacting with continuous integration and reviewing contributions from other team members. Users performing these tasks need tools that allow them to deeply understand the changes and provide meaningful feedback of both comments and code suggestions. These are specifically addressed by the following GitLab Personas: