In our previous post, we talked about merge request (MR) Reviews. We explained how the GitLab Workflow extension helps you review MRs without leaving VS Code. Since releasing and polishing the MR reviews, we've been working on improvements to the extension. In this post, we will show you how the latest features fit into your workflow.
Do you have a lot to say? Use a snippet patch!
On GitLab's web UI there's the "suggestions" feature. It's handy for suggesting small changes in the MR review. The VS Code platform doesn't let us recreate the same experience, but the extension offers an alternative: Snippet patches.
Snippet patches are code changes (git patches) of arbitrary size shared as GitLab snippets. Because they don't have a size limit, they are perfect for suggesting changes to multiple files during the MR review.
The extension has two commands, Create snippet patch
and Apply snippet patch
. These commands use git diff
and git apply
, respectively, which means people can still apply the snippet patch even if they don't use the GitLab Workflow extension.
If a suggestion in the comment is a hammer, then a snippet patch is a pneumatic tamping machine. Next time you'll review an MR, and you see a lot of space for improvement, remember the adage: "A patch is worth a thousand words".
What's going on with my pipeline? - Improved CI status display
The extension always showed the latest CI pipeline status in both the status bar and the sidebar. However, if you tried to gauge your pipeline status, you probably run into one or more surprises. The status was hard to understand. Sometimes it related to a different branch, or it was out of date.
We've made the pipeline status much more reliable and readable. For starters, you can now see individual jobs and their status in the sidebar. Click on any job, and the extension opens a browser window with the GitLab job page.
We also improved the consistency of showing the pipeline status. The status bar and sidebar are now in sync and always showing pipeline for the current branch.
We are excited about the cleaner code. It makes it easier for anyone to contribute functionality. If you'd be interested in giving it a shot, we recommend starting with the Download artifacts from the latest pipeline feature request.
VS Code CI Pipeline status overview from GitLab extension.
Make the MR your own - Working with checked out code
Two recent improvements play well together to make your review more interactive. They help you spend less time on actions that don't directly relate to reviewing code. These improvements let you check out the MR branch and open a local file during a review.
Check out the MR branch
You can checkout any MR locally, as long as it is not coming from a forked project. Right-click the MR in the side tree and select "Checkout MR Branch". After the command finishes, you'll have the MR branch checked out in your project. Now you can review and run the code.
{: .shadow.medium.center}Open a local file during a review
When you look at a changed file in an MR, you can click on a small "file" icon in the top-right corner. The extension will open the same file in your local repository.
If your local branch is different from the MR branch, the local file might not be the same as the MR file.
Opening the local file is useful when you want to explore the surroundings of the file quickly. The VS Code automatically focuses the file in the file tree, which lets you see all the neighbouring files.
{: .shadow.medium.center}Commitment problems? Browse repositories without checking them out
At GitLab, we've got some large repositories. The largest, which all GitLabbers use daily, is www-gitlab-com, the website you see when you visit about.gitlab.com
. This 6 GB colossus takes several minutes to check out.
Exploring this repository is a perfect use case for our latest feature: Remote Repositories, contributed by Ethan Reesor, a community member.
Run the GitLab: Open Remote Repository
command, pick which project and branch you want to use, and voilĂ . The extension opens the repository in your local workspace, but it doesn't store data on your local machine.
Remote repositories are useful when you want to browse a repository for a reference but don't plan to change the code.
This is the first iteration, and it's got some limitations - you can't use full-text search, fuzzy file navigation, and the files are read-only. It's useful nonetheless.
Thank you community!
Most of the features introduced in this post are either implemented or suggested by a community member. Ahmed Mohamadeen suggested opening local file during MR review, Musisimaru created initial implementation of checking out MR branch, and Ethan Reesor implemented remote repositories.
If you'd like to shape the future of the GitLab Workflow VS Code extension, you can create issues in our issue tracker, or look for issues where we accept MRs. Our CONTRIBUTING guide is an excellent place to start.
Cover image by Ljubica Petkovic, licensed under CC BY-SA 4.0